Lewati ke konten

Rekayasa··2 menit baca

Cara Kami Mengukur 2.000 Permintaan per Detik, dan Apa yang Patah Duluan

Upstream simulasi yang menahan tiap permintaan beberapa detik, beban dari mesin terpisah, dan pemeriksaan uang sesudahnya. Metode di balik angka kapasitas kami.

Tim Pecutin

Read in English

Angka kapasitas mudah digelembungkan. Arahkan pembangkit beban ke gateway yang upstream-nya menjawab dalam satu milidetik dan kamu bisa melaporkan angka berapa saja. Berikut cara kami mengukurnya, dan kenapa metodenya lebih penting daripada judulnya.

Kenapa upstream-nya harus lambat

Panggilan model sungguhan butuh beberapa detik. Itu mengubah segalanya soal beban. Pada 200 permintaan per detik dengan upstream 1 ms, hanya sekitar 0,2 permintaan yang hidup bersamaan. Dengan upstream 3,75 detik, ada sekitar 750. Biaya CPU per permintaan sama; state yang harus ditahan gateway tiga ordo lebih besar.

Jadi upstream simulasi kami menunggu 3 detik ditambah acak 0 sampai 1,5 detik sebelum menjawab. p95-nya sendiri sekitar 4,4 detik, artinya latensi di atas itu adalah antrean di gateway, bukan upstream.

Beban dari tempat lain

Menjalankan pembangkit beban di mesin yang sama dengan gateway menghasilkan lebih banyak kesimpulan salah daripada apa pun dalam pekerjaan ini: keduanya berebut CPU dan jalur jaringannya tidak realistis. Setiap angka yang kami terbitkan dibangkitkan dari mesin terpisah.

Hasil di mesin produksi

Di mesin produksi, AMD EPYC dengan 8 vCPU dedicated dan RAM 32 GB, beban datang dari dua mesin 4-core terpisah.

ditawarkandilayanip95overhead gateway
1.200/dtk100%4.445 ms+20 ms
2.000/dtk100%4.685 ms+260 ms
2.400/dtk1.433 jatuh8.925 ms+4.500 ms

Titik amannya 2.000 permintaan per detik: 360.001 permintaan berturut-turut selama tiga menit tanpa satu pun kegagalan transport, 5xx, atau 429. Pada laju itu mesin memakai sekitar 72% CPU dan RAM 8,8 GB.

Dinding pertama bukan CPU

Sebelum disetel, mesin ini mentok di sekitar 1.455 permintaan per detik sementara CPU baru 54%. Penyebabnya batas bawaan 5.000 koneksi per host upstream. Dengan permintaan yang berlangsung 3,75 detik, itu membatasi throughput di sekitar 1.333 per detik. Menaikkan satu pengaturan itu menghapus beberapa detik latensi.

Lalu kami memeriksa uangnya

Uji yang hanya menghitung galat bisa menyembunyikan bug tagihan. Sesudah soak kami menghitung baris: 360.001 permintaan menghasilkan tepat 360.001 baris ledger baru, dan untuk ke-60 akun uji saldonya sama dengan jumlah ledgernya.

Pertanyaan yang sering diajukan

Apakah 2.000 permintaan per detik itu maksimum?

Itu titik aman: laju tertinggi dengan nol kegagalan dan latensi mendekati latensi upstream sendiri. Di atasnya, latensi naik dan permintaan mulai jatuh.

Apakah angka ini memakai penyedia sungguhan?

Tidak. Angka ini mengukur gateway itu sendiri terhadap upstream simulasi, satu-satunya cara memisahkan overhead-nya.

Berhenti mengurus akun satu per satu. Mulai dari satu kunci.