Dokumen ini menjelaskan cara menafsirkan hasil performa di AlloyDB Omni pada VM. Dokumen ini mengasumsikan bahwa Anda sudah memahami PostgreSQL.
Saat Anda membuat grafik throughput dari waktu ke waktu saat variabel lain diubah, biasanya Anda akan melihat peningkatan throughput hingga throughput mencapai titik kehabisan resource.
Gambar berikut menunjukkan grafik penskalaan throughput yang umum. Seiring bertambahnya jumlah klien, beban kerja dan throughput akan meningkat hingga semua resource habis.
Idealnya, saat Anda melipatgandakan beban pada sistem, throughput juga akan berlipat ganda. Dalam praktiknya, akan ada pertentangan pada resource yang menyebabkan peningkatan throughput yang lebih kecil. Pada titik tertentu, kehabisan resource atau pertentangan akan menyebabkan throughput menjadi datar atau bahkan menurun. Jika Anda mengoptimalkan throughput, ini adalah poin penting yang harus diidentifikasi karena mendorong upaya Anda untuk menyesuaikan aplikasi atau sistem database guna meningkatkan throughput.
Alasan umum throughput menjadi stabil atau menurun meliputi hal-hal berikut:
- Kehabisan resource CPU di server database
- Kehabisan resource CPU di klien sehingga server database tidak menerima lebih banyak tugas
- Pertentangan kunci database
- Waktu tunggu I/O saat data melebihi ukuran kumpulan buffer Postgres
- Waktu tunggu I/O karena penggunaan mesin penyimpanan
- Bottleneck bandwidth jaringan yang menampilkan data ke klien
Latensi dan throughput berbanding terbalik. Seiring meningkatnya latensi, throughput akan menurun. Secara intuitif, hal ini masuk akal. Saat bottleneck mulai terjadi, operasi mulai memerlukan waktu lebih lama dan sistem melakukan lebih sedikit operasi per detik.
Grafik penskalaan latensi menunjukkan perubahan latensi seiring meningkatnya beban yang ditempatkan pada sistem. Latensi tetap relatif konstan hingga terjadi gesekan karena pertentangan resource. Titik infleksi kurva ini umumnya sesuai dengan perataan kurva throughput dalam grafik penskalaan throughput.
Cara lain yang berguna untuk mengevaluasi latensi adalah sebagai histogram. Dalam representasi ini, kami mengelompokkan latensi ke dalam bucket dan menghitung jumlah permintaan yang masuk ke setiap bucket.
Histogram latensi ini menunjukkan bahwa sebagian besar permintaan berada di bawah 100 milidetik, dan latensi lebih dari 100 milidetik. Memahami penyebab permintaan dengan ekor latensi yang lebih lama dapat membantu menjelaskan variasi performa aplikasi yang terlihat. Penyebab long tail peningkatan latensi sesuai dengan peningkatan latensi yang terlihat pada grafik penskalaan latensi standar dan perataan grafik throughput.
Histogram latensi paling berguna saat ada beberapa modalitas dalam aplikasi. Modalitas adalah kumpulan kondisi operasi normal. Misalnya, sebagian besar waktu aplikasi mengakses halaman yang ada dalam cache buffer. Sebagian besar waktu, aplikasi memperbarui baris yang ada, tetapi mungkin ada beberapa mode. Terkadang, aplikasi mengambil halaman dari penyimpanan, menyisipkan baris baru, atau mengalami pertentangan kunci.
Saat aplikasi mengalami berbagai mode operasi ini dari waktu ke waktu, histogram latensi akan menampilkan beberapa modalitas ini.
Gambar ini menunjukkan histogram bimodal standar dengan sebagian besar permintaan dilayani dalam waktu kurang dari 100 milidetik, tetapi ada cluster permintaan lain yang memerlukan waktu 401-500 milidetik. Memahami penyebab modalitas kedua ini dapat membantu meningkatkan performa aplikasi Anda. Bisa juga ada lebih dari dua modalitas.
Modalitas kedua mungkin disebabkan oleh operasi database normal, infrastruktur dan topologi heterogen, atau perilaku aplikasi. Beberapa contoh yang perlu dipertimbangkan adalah sebagai berikut:
- Sebagian besar akses data berasal dari kumpulan buffer PostgreSQL, tetapi beberapa berasal dari penyimpanan
- Perbedaan latensi jaringan untuk beberapa klien ke server database
- Logika aplikasi yang melakukan operasi yang berbeda-beda bergantung pada input atau waktu
- Pertentangan kunci yang sporadik
- Lonjakan aktivitas klien