Mengapa apl SQL yang banyak bercakap merangkak melalui VPN dan apa yang perlu dikelompokkan
Skrin yang melepaskan seratus pertanyaan bergantung membayar perjalanan pergi balik seratus kali. Kira penantian, kelompokkan yang bebas, kemudian pindahkan pelaksanaan.
Borang yang terbuka dalam kurang daripada satu saat pada LAN mengambil masa lima saat melalui VPN, manakala salinan fail pada pautan yang sama berjalan pada kelajuan penuh. Perbezaannya bukan lebar jalur. Borang menunggu urutan jawapan dan membayar perjalanan pergi balik penuh pada setiap langkah, manakala salinan fail mengekalkan bait sentiasa bergerak. Kira penantian itu sebelum anda menyentuh talian akses.
Gejalanya ialah skrin, bukan pertanyaan
Setiap pertanyaan pada skrin itu boleh jadi pantas dan skrin itu masih boleh lambat, kerana jumlahnya ialah hasil tambah penantian, bukan hasil tambah masa pelaksanaan. Pernyataan yang berjalan dalam dua milisaat masih menelan satu perjalanan pergi balik penuh apabila klien mesti menerima hasilnya sebelum menghantar yang seterusnya. Pada laluan dengan kependaman empat puluh milisaat, seratus panggilan bergantung terkumpul sekitar empat saat sebelum sebarang kerja pemaparan berlaku. Aritmetik ini ialah model penantian, bukan penanda aras pautan anda.
Itulah sebabnya ujian kelajuan kelihatan tidak bersalah. Pemindahan pukal mengukur daya pemprosesan, borang yang banyak bercakap mengukur kependaman, dan VPN boleh cemerlang dalam satu sambil kekal biasa dalam yang lain. Jadi mendiagnosis skrin bermakna mengukur skrin, bukan pautan.
Catat masa hujung ke hujung satu tindakan pengguna sebelum mengubah apa-apa. Nombor itu satu-satunya garis dasar yang boleh memberitahu anda sama ada pembaikan kemudian berkesan.
Kira penantian berturutan dalam satu tindakan pengguna
Instrumentasikan klien dan bukannya meneka. Dalam psql, \timing on mencetak masa berlalu bagi setiap pernyataan, dan EXPLAIN (ANALYZE, BUFFERS) menunjukkan berapa banyak masa itu sebenarnya dihabiskan pelayan untuk kerja tersebut.
Jurang antara kedua-dua nombor itu ialah overhed rangkaian dan klien anda. Jika satu pernyataan dilaksanakan dalam dua milisaat dan klien merekodkan enam puluh, baki lima puluh lapan ialah perjalanan dan pemprosesan tempatan, dan tiada indeks akan menghapuskannya. Ulang perbandingan itu untuk setiap pernyataan yang dikeluarkan skrin dan jumlahkan jurang, bukan masa pelaksanaan.
Tulis hasilnya sebagai kiraan penantian berturutan. Itulah kuantiti yang dua bahagian seterusnya mampu kurangkan, dan ia nombor yang boleh anda bincangkan dengan bukti.
Kelompokkan panggilan bebas, kekalkan yang bergantung
Dua pernyataan yang tidak membaca hasil satu sama lain boleh bergerak bersama dan dikumpul sekali, yang menukar dua penantian kepada satu. Dua pernyataan yang kedua memerlukan nilai daripada yang pertama tidak boleh, kerana kebergantungan itu nyata dan mengelompokkannya akan mengubah apa yang program lakukan. Susun panggilan ke dalam dua longgokan itu sebelum menulis semula apa-apa, dan saiz setiap longgokan memberitahu anda apa yang mungkin.
Kerja berasaskan set menghapuskan penantian dengan lebih menyeluruh daripada pengelompokan. Satu pertanyaan yang memulangkan baris yang gelung ambil satu demi satu menghapuskan gelung serta perjalanan pergi balik. Cari gelung dahulu, kerana ia biasanya keuntungan yang lebih besar dan perubahan yang lebih mudah disemak.
Kelompok masih perlu mengekalkan pengendalian ralat dan sempadan transaksi. Menggabungkan pernyataan tidak berkaitan menjadi satu rentetan bukan pengoptimuman yang selamat, dan kelompok yang menyembunyikan pernyataan gagal di sebalik penyerahan berjaya lebih teruk daripada penantian yang dijimatkannya.
Guna semula sambungan sebelum membeli lebar jalur
Sambungan baharu menelan kos penyelesaian nama, jabat tangan TCP, rundingan TLS dan pengesahan, dan pada laluan berkependaman tinggi setiap satu daripadanya ialah satu lagi perjalanan pergi balik sebelum pertanyaan pertama berjalan. Kolam sambungan wujud untuk membayar kos itu sekali setiap proses dan bukan sekali setiap panggilan.
Dalam ADO.NET, menutup atau dispose sambungan terkumpul memulangkannya untuk diguna semula dan bukannya membuka yang fizikal baharu, jadi corak yang kelihatan seperti kebocoran selalunya penggunaan yang betul. Sahkan kolam benar-benar digunakan dan jangan andaikan: log penciptaan sambungan fizikal, atau perhatikan kiraan sesi pada pelayan semasa skrin berjalan. Panduan prestasi SQL menyatakan perkara yang sama tentang mengurangkan perjalanan pergi balik dan mengelompokkan panggilan ad hoc yang kerap, dengan contoh khusus perkhidmatan yang patut anda petakan pada penggunaan anda sendiri.
Pengumpulan menghapuskan kos persediaan dan membiarkan penantian pertanyaan bersiri tidak tersentuh. Ia prasyarat untuk pengukuran bersih, bukan pembaikan dengan sendirinya.
Timbang pemindahan pelaksanaan lebih dekat dengan data
Menjalankan apl berhampiran pangkalan data menggantikan banyak pertukaran pangkalan data jauh dengan satu sesi paparan jauh. Untuk beban kerja yang banyak bercakap itu boleh jadi perubahan besar, dan ia perubahan operasi sama seperti perubahan prestasi: pengurusan sesi, kawalan akses, penggunaan perisian dan pengalaman pengguna semuanya bergerak bersama apl.
Ukur antara muka sebenar dan data yang dipindahkannya sebelum menganggap mana-mana arah lebih pantas. Sesi desktop jauh memindahkan piksel, dan skrin dengan grafik padat boleh berprestasi lebih teruk pada laluan yang sama berbanding pertanyaan yang digantikannya, terutamanya apabila klien melukis semula secara berterusan.
Kemudian ulang tindakan asal dan bandingkan tiga nombor: penantian berturutan, isipadu hasil dan masa penyiapan hujung ke hujung. Penambahbaikan yang mengubah tugas pengguna yang diukur sambil mengekalkan ketepatan data dan dasar akses ialah yang berbaloi dikekalkan.