Mengapa aplikasi SQL yang cerewet merangkak lewat VPN dan apa yang perlu dibatch

Formulir yang tampil di bawah satu detik di jaringan lokal butuh lima detik lewat VPN, sementara salinan berkas pada tautan yang sama berjalan dengan kecepatan penuh. Perbedaannya bukan lebar pita. Formulir menunggu rangkaian jawaban dan membayar penuh perjalanan pulang-pergi di setiap langkah, sedangkan salinan berkas menjaga bita tetap bergerak terus-menerus. Hitung penantian itu sebelum Anda menyentuh jalur akses.

Gejalanya adalah layar, bukan kueri

Setiap kueri di layar itu bisa cepat dan layarnya tetap bisa lambat, karena totalnya adalah jumlah penantian, bukan jumlah waktu eksekusi. Pernyataan yang berjalan dalam dua milidetik tetap memakan satu perjalanan penuh ketika klien harus menerima hasilnya sebelum mengirim yang berikutnya. Pada jalur dengan latensi empat puluh milidetik, seratus panggilan dependen menumpuk sekitar empat detik sebelum pekerjaan penggambaran apa pun dimulai. Aritmetika ini adalah model penantian, bukan pengukuran tautan Anda.

Itulah sebabnya uji kecepatan tampak tidak bersalah. Transfer besar mengukur laju, formulir cerewet mengukur latensi, dan VPN bisa unggul di satu hal sementara biasa saja di hal lain. Jadi mendiagnosis layar berarti mengukur layar, bukan tautan.

Catat waktu ujung ke ujung satu tindakan pengguna sebelum mengubah apa pun. Angka itu adalah satu-satunya garis dasar yang bisa memberi tahu apakah perbaikan kemudian berhasil.

Hitung penantian berurutan dalam satu tindakan pengguna

Ukur di klien alih-alih menebak. Di psql, \timing on mencetak waktu berlalu setiap pernyataan, dan EXPLAIN (ANALYZE, BUFFERS) menunjukkan berapa banyak waktu itu yang benar-benar dipakai server untuk pekerjaan.

Selisih antara kedua angka itu adalah beban jaringan dan klien Anda. Jika pernyataan selesai dalam dua milidetik dan klien mencatat enam puluh, lima puluh delapan sisanya adalah perjalanan dan pemrosesan lokal, dan tidak ada indeks yang menghapusnya. Ulangi perbandingan itu untuk setiap pernyataan yang dikeluarkan layar dan jumlahkan selisihnya, bukan waktu eksekusinya.

Tuliskan hasilnya sebagai hitungan penantian berurutan. Itulah besaran yang bisa dikurangi dua bagian berikutnya, dan itu angka yang bisa Anda debat dengan bukti.

Batch panggilan independen, pertahankan yang dependen

Dua pernyataan yang tidak membaca hasil satu sama lain dapat bepergian bersama dan dikumpulkan sekali, yang mengubah dua penantian menjadi satu. Dua pernyataan yang keduanya membutuhkan nilai dari yang pertama tidak bisa, karena ketergantungannya nyata dan membatch-nya akan mengubah apa yang dilakukan program. Pilah panggilan ke dalam dua tumpukan itu sebelum menulis ulang apa pun, dan ukuran tiap tumpukan memberi tahu Anda apa yang mungkin.

Pekerjaan berbasis himpunan menghapus penantian lebih menyeluruh daripada pembatchan. Satu kueri yang mengembalikan baris yang tadinya diambil perulangan satu per satu menghilangkan perulangannya sekaligus perjalanannya. Cari perulangannya lebih dulu, karena biasanya itulah keuntungan terbesar dan perubahan yang lebih mudah ditinjau.

Batch tetap harus mempertahankan penanganan galat dan batas transaksi. Menggabungkan pernyataan yang tak berhubungan ke dalam satu string bukanlah optimasi yang aman, dan batch yang menyembunyikan pernyataan gagal di balik pengiriman yang berhasil lebih buruk daripada penantian yang dihematnya.

Gunakan ulang koneksi sebelum membeli lebar pita

Koneksi baru memakan resolusi nama, jabat tangan TCP, negosiasi TLS, dan autentikasi, dan pada jalur berlatensi tinggi masing-masing itu adalah perjalanan lain sebelum kueri pertama berjalan. Kolam koneksi ada untuk membayar biaya itu sekali per proses, bukan sekali per panggilan.

Di ADO.NET, menutup atau membuang koneksi dari kolam mengembalikannya untuk dipakai ulang alih-alih membuka koneksi fisik baru, sehingga pola yang tampak seperti kebocoran sering justru penggunaan yang benar. Pastikan kolam benar-benar dipakai alih-alih menganggapnya: catat pembuatan koneksi fisik, atau pantau jumlah sesi di server selagi layar berjalan. Panduan kinerja SQL menyatakan hal yang sama tentang mengurangi perjalanan pulang-pergi dan membatch panggilan ad hoc yang sering, dengan contoh khusus layanan yang sebaiknya Anda petakan ke penerapan Anda sendiri.

Pengkolaman menghapus biaya penyiapan dan membiarkan penantian kueri berurutan tak tersentuh. Itu prasyarat untuk pengukuran yang bersih, bukan perbaikan tersendiri.

Timbang memindahkan eksekusi lebih dekat ke data

Menjalankan aplikasi dekat basis data menggantikan banyak pertukaran basis data jarak jauh dengan satu sesi tampilan jarak jauh. Untuk beban kerja cerewet, itu bisa menjadi perubahan besar, dan itu perubahan operasional sebanyak perubahan kinerja: manajemen sesi, kendali akses, penyebaran perangkat lunak, dan pengalaman pengguna semuanya ikut berpindah bersama aplikasi.

Ukur antarmuka sebenarnya dan data yang dipindahkannya sebelum menganggap salah satu arah lebih cepat. Sesi desktop jarak jauh memindahkan piksel, dan layar dengan grafik padat bisa berperforma lebih buruk pada jalur yang sama daripada kueri yang digantikannya, terutama ketika klien menggambar ulang terus-menerus.

Lalu ulangi tindakan semula dan bandingkan tiga angka: penantian berurutan, volume hasil, dan waktu penyelesaian ujung ke ujung. Perbaikan yang mengubah tugas pengguna yang diukur sambil mempertahankan ketepatan data dan kebijakan akses itulah yang layak dipertahankan.