Redis melalui VPN terasa lambat: kurangkan perjalanan pergi balik setiap permintaan

Halaman yang menjawab dalam 200 ms terhadap Redis setempat mengambil masa empat saat sebaik sahaja klien berada di belakang VPN, manakala pembilang pelayan kekal terbiar. Log perlahan tidak menunjukkan apa-apa melebihi satu milisaat, graf CPU rata dan instans melayan klien lain tanpa aduan. Apa yang berubah ialah jarak, dan apa yang menggandakan jarak ialah bilangan kali kod anda berhenti dan menunggu. Telusuri laluan permintaan dari klien ke luar dan penyelesaiannya hampir selalu lebih sedikit tungguan berturutan, bukan pelayan yang lebih pantas.

Mulakan dari klien, bukan dari metrik pelayan

Perhatikan proses klien antara arahan pertama dan terakhir. Jika jejak menunjukkan balasan, jeda, kemudian arahan seterusnya, anda membayar satu perjalanan penuh bagi setiap arahan dan tiada pelarasan pelayan akan mengubahnya. Log perlahan ialah alat yang salah di sini, kerana ia merekodkan masa pelaksanaan dan sengaja mengecualikan I/O komunikasi. Log perlahan yang bersih di sebelah titik akhir yang perlahan ialah tanda masalah perjalanan pergi balik.

Ukur laluan itu sendiri sebelum menyentuh kod. redis-cli -h redis.example.internal --latency menghantar PING berulang dan mencetak purata masa permintaan dan balasan, iaitu kos anda bagi setiap pertukaran. Darabkannya dengan bilangan arahan berturutan dalam satu tindakan pengguna dan anda ada had bawah untuk titik akhir.

Kira perjalanan pergi balik yang benar-benar diperlukan oleh satu tindakan pengguna

Ambil satu titik akhir dan catat setiap panggilan Redis mengikut urutan, termasuk yang tersembunyi di dalam ORM, perisian tengah sesi atau carian bendera ciri. Kebanyakan titik akhir perlahan melakukan dua puluh atau tiga puluh panggilan sedangkan tiga sudah cukup, dan yang tersembunyi biasanya majoriti.

Rantaian kebergantungan tidak boleh dilipat: jika arahan kedua memerlukan kunci yang dikembalikan oleh yang pertama, tungguan itu nyata dan satu-satunya pilihan ialah model data lain atau operasi sebelah pelayan yang menyatakan keseluruhan langkah sekali gus. Bacaan bebas ialah kes lain, kerana tiada apa memaksa anda menunggu balasan pertama sebelum menghantar yang kedua. Tandakan setiap panggilan sebagai bergantung atau bebas sebelum mengubah apa-apa, dan bentuk penyelesaiannya menjadi jelas.

Angka yang penting ialah tungguan berturutan, bukan jumlah arahan. Tiga puluh arahan dalam satu kelompok tetap hanya memakan satu tungguan.

Kelompokkan hanya arahan yang tidak bergantung antara satu sama lain

Saluran paip meletakkan arahan bebas dalam baris gilir dan mengumpul balasan mengikut urutan, menukar N tungguan menjadi satu. Kebanyakan klien menawarkannya sebagai blok, panggilan balik atau pengurus konteks dan bukan mod sambungan berasingan, jadi semak API yang disediakan versi terpasang anda. Keuntungannya meningkat dengan masa perjalanan, dan itulah sebabnya ia penting di VPN dan hampir tidak dirasai di localhost.

import redis

r = redis.Redis(host="redis.example.internal", port=6379, socket_timeout=2)
pipe = r.pipeline(transaction=False)
for key in ("user:1001", "user:1002", "user:1003"):
    pipe.get(key)
print(pipe.execute())

Hantar transaction=False apabila anda hanya mahu pengelompokan. Dengan tetapan lalai klien membalut kelompok dalam MULTI dan EXEC, yang menjadikannya atomik dan mengubah apa yang boleh diperhatikan oleh klien lain semasa dalam perjalanan. Keatomikan ialah keputusan ketepatan, bukan tombol prestasi, dan saluran paip bukan transaksi hanya kerana kedua-duanya mengurangkan perjalanan pergi balik.

Baca setiap balasan dan bukan hanya penghantaran kelompok. Arahan dalam baris gilir boleh memulangkan ralat sementara kelompok secara keseluruhan selesai, dan klien yang membuang senarai balasan menukar penulisan yang gagal menjadi penulisan senyap. Bandingkan panjang senarai balasan dengan bilangan arahan yang anda masukkan ke dalam baris gilir.

Kekalkan sambungan hidup antara tindakan

Setiap sambungan baharu membayar penyelesaian nama, jabat tangan TCP, jabat tangan TLS dan AUTH, dan melalui VPN setiap satunya ialah perjalanan yang tidak boleh anda kelompokkan. Cipta klien sekali bagi setiap proses dan guna semula, atau gunakan kolam yang disediakan pustaka anda dengan saiz terhad. Menyambung semula bagi setiap permintaan ialah punca kedua paling biasa bagi gejala ini selepas tungguan bagi setiap arahan.

Simpan nama hos peribadi dalam konfigurasi dan bukan alamat literal. Pengesahan sijil dan identiti perkhidmatan masih terpakai pada rangkaian peribadi, dan penyematan IP rosak pada saat penyedia menomborkan semula subrangkaian. Jika penyelesaian nama ialah bahagian yang perlahan, betulkan laluan penyelesai dan bukan rentetan sambungan.

Tetapkan tamat masa soket yang jelas supaya terowong tersekat gagal cepat dan bukan menggantung pekerja. Kemudian sahkan kolam benar-benar diguna semula dengan merekodkan penciptaan sambungan dalam klien.

Tentukan saiz kelompok sebelum ia menjadi masalah memori

Redis menyimpan balasan dalam baris gilir sepanjang tempoh kelompok, dan klien menyimpan hasil yang dihurai selepas itu. Saluran paip sepuluh ribu nilai besar menukar tungguan rangkaian dengan lonjakan memori dan jeda panjang di kedua-dua hujung.

Pilih saiz kelompok berdasarkan isi padu balasan dan bukan bilangan arahan. Beberapa ratus arahan kecil dalam satu kelompok biasanya selesa, manakala seratus muatan beberapa kilobait tidak. Bahagikan mengikut bait dan juga bilangan, dan kekalkan setiap kelompok dalam bajet kependaman yang benar-benar dimiliki titik akhir.

Ukur dari hujung ke hujung selepas perubahan: redis-cli -h redis.example.internal --latency-history menunjukkan sama ada laluan itu sendiri stabil, dan pemasa permintaan anda sendiri menunjukkan sama ada titik akhir bertambah baik. Jika titik akhir masih perlahan sementara sejarah kependaman rata, kos yang tinggal ialah kerja sebelah pelayan atau pensirian anda sendiri, dan langkah seterusnya ialah profil pengendali dan bukan satu lagi perubahan pengelompokan.