Untungnya, biasanya tidak demikian.
Variabel yang hilang dalam persamaan Anda adalah bagaimana database Anda dan server aplikasi Anda dan apa pun di tumpukan Anda menangani konkurensi .
Untuk mengilustrasikan ini secara ketat dari perspektif MySQL, saya menulis program klien uji yang menetapkan jumlah koneksi tetap ke server MySQL, masing-masing di utasnya sendiri (dan karenanya, dapat mengeluarkan kueri ke server pada waktu yang kira-kira bersamaan) .
Setelah semua utas memberi isyarat kembali bahwa mereka terhubung, sebuah pesan dikirim ke semuanya pada saat yang sama, untuk mengirim kueri mereka.
Ketika setiap utas mendapat sinyal "pergi", ia melihat waktu sistem saat ini, lalu mengirimkan kueri ke server. Saat mendapat respons, ia melihat waktu sistem lagi, lalu mengirim semua informasi kembali ke utas utama, yang membandingkan pengaturan waktu dan menghasilkan output di bawah.
Program ini ditulis sedemikian rupa sehingga tidak menghitung waktu yang dibutuhkan untuk membuat koneksi ke server, karena dalam aplikasi yang berperilaku baik koneksi akan dapat digunakan kembali.
Kuerinya adalah SELECT SQL_NO_CACHE COUNT(1) FROM ... (tabel InnoDB dengan sekitar 500 baris di dalamnya).
threads 1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads 2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads 4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads 8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841
Waktu dalam hitungan detik. Min/maks/rata-rata adalah waktu terbaik/terburuk/rata-rata yang diamati saat menjalankan kueri yang sama. Pada konkurensi 64, Anda melihat kasing terbaik tidak jauh berbeda dari kasing terbaik dengan hanya 1 kueri. Tapi take-away terbesar di sini adalah total kolom runtime. Nilai itu adalah perbedaan waktu sejak utas pertama mengirim kuerinya (mereka semua mengirim kueri pada dasarnya pada waktu yang sama, tetapi "tepatnya" pada waktu yang sama tidak mungkin karena saya tidak memiliki mesin 64-inti untuk menjalankan skrip uji aktif) hingga saat utas terakhir menerima responsnya.
Pengamatan:kabar baiknya adalah 64 kueri yang mengambil rata-rata 0,005586 detik pasti tidak memerlukan 64 * 0,005586 detik =0,357504 detik untuk dieksekusi... bahkan tidak memerlukan 64 * 0,001089 (waktu kasus terbaik) =0,069696 Semua dari kueri tersebut dimulai dan diselesaikan dalam 0,019841 detik... atau hanya sekitar 28,5% dari waktu yang secara teoritis dibutuhkan untuk kueri tersebut dijalankan satu demi satu.
Berita buruknya, tentu saja, adalah bahwa waktu eksekusi rata-rata pada kueri ini pada konkurensi 64 adalah lebih dari 5 kali lebih tinggi daripada waktu ketika hanya dijalankan sekali... dan kasus terburuknya hampir 14 kali lebih tinggi. Tapi itu masih jauh lebih baik daripada perkiraan linier dari waktu eksekusi kueri tunggal yang disarankan.
Namun, hal-hal tidak berskala tanpa batas. Seperti yang Anda lihat, kinerjanya menurun seiring dengan konkurensi dan pada titik tertentu akan menurun -- mungkin cukup cepat -- saat kami mencapai hambatan mana pun yang terjadi lebih dulu. Jumlah tabel, sifat kueri, penguncian apa pun yang ditemui, semuanya berkontribusi pada kinerja server di bawah beban bersamaan, seperti halnya kinerja penyimpanan Anda, ukuran, kinerja, dan arsitektur, memori sistem, dan internal MySQL -- beberapa di antaranya dapat disetel dan beberapa di antaranya tidak.
Tapi tentu saja, database bukan satu-satunya faktor. Cara server aplikasi menangani permintaan bersamaan dapat menjadi bagian besar lain dari kinerja Anda yang sedang dimuat, terkadang lebih besar dari database, dan terkadang lebih sedikit.
Satu hal besar yang tidak diketahui dari tolok ukur Anda adalah berapa banyak waktu yang dihabiskan oleh database untuk menjawab pertanyaan, berapa banyak waktu yang dihabiskan oleh server aplikasi yang menjalankan bisnis logika, dan berapa banyak waktu yang dihabiskan oleh kode yang merender hasil halaman menjadi HTML.
