Analisis Distribusi Wrk Latency yang Tidak Akurat

wrk adalah alat pengujian stres HTTP yang hebat yang dibangun di atas proyek-proyek sumber terbuka seperti Redis, NGINX, Node.js, dan LuaJIT, memanfaatkan kekuatan mereka dalam hal event-driven, parsing HTTP, kinerja tinggi, fleksibilitas, serta kemampuan untuk menulis skrip Lua sendiri untuk menghasilkan permintaan pengujian.

Meskipun wrk tidak memiliki kasus uji dan penulisnya muncul sekitar sekali setahun untuk menggabungkan kode, hal itu tidak menghentikan kita untuk menggunakan wrk sebagai alat pilihan untuk pengujian kinerja dan fuzz testing. Jika Anda masih menggunakan ab berbasis multi-thread, sangat layak untuk mencoba wrk.

Berikut adalah bagian statistik dari distribusi penundaan dari hasil wrk.

    Latency Distribution
     50%    1.20ms
     75%  595.78ms
     90%  899.11ms
     99%    1.00s

Contoh ini berarti bahwa 50% permintaan selesai dalam 1,2ms, 90% permintaan selesai dalam 899 ms, dan 99% permintaan selesai dalam 1 detik.

Ketika kami menggunakan wrk untuk melakukan pengujian stres pada produk kami sendiri, kami menemukan bahwa sebagian besar permintaan dalam statistik penundaan wrk selesai dalam beberapa milidetik, tetapi sebagian kecil permintaan memiliki penundaan lebih dari 100 milidetik. Untuk sistem yang dibangun dengan OpenResty, memiliki penundaan sebesar itu tidaklah sangat ilmiah.

Meskipun solusi akhir untuk masalah ini sangat sederhana, analisis dan penentuan posisi masalahnya agak berbelit-belit dan memakan waktu beberapa hari. Solusi akhirnya tidak penting; yang menarik adalah proses dan cara berpikir tentang masalah tersebut.

Saat kami menghadapi masalah penundaan, reaksi pertama kami adalah bahwa ada penyumbatan di suatu tempat dalam kode atau sistem. Karena sistemnya kompleks, kami menawarkan flame charts.

Tidak ada skrip systemtap siap pakai untuk menganalisis masalah jenis ini, sehingga membutuhkan waktu untuk menulisnya. Namun, setelah beberapa kali menyesuaikan skrip systemtap, tidak ada penundaan signifikan yang terdeteksi, yang jelas tidak konsisten dengan hasil wrk. Kami menduga bahwa skrip mungkin tidak sempurna dan mungkin melewatkan beberapa fungsi yang tidak terhubung. Namun, kami juga meragukan kebenaran hasil wrk.

Kami berbalik dan mencoba menentukan apakah statistik wrk salah, atau apakah ini memang masalah server. Kami mengumpulkan semua paket dari uji crush pada server tempat wrk berada, mengurutkannya berdasarkan waktu yang dihabiskan, dan terkejut menemukan bahwa hasilnya sangat berbeda dari statistik penundaan wrk, dengan tidak ada permintaan yang melebihi 100 milidetik. Saya mengulangi tes di atas beberapa kali dan hasilnya konsisten.

Sekarang tujuannya jelas, cukup haluskan kode wrk tentang statistik penundaan. Kekhawatiran terbesar adalah ada bug dalam statistik internal wrk, yang tidak mudah diperbaiki, mengingat ini adalah proyek tanpa kasus uji apa pun.

Kami menelusuri logika statistik wrk dan menambahkan log di awal dan akhir, dan lega menemukan bahwa statistik tentang penundaan itu benar. Namun, sebelum mencetak hasil akhir, ada kode statistic correction.

    if (complete / cfg.connections > 0) {
        int64_t interval = runtime_us / (complete / cfg.connections);
        stats_correct(statistics.latency, interval);
    }

Menurut penilaian if ini, setiap kali data piezometrik dihasilkan, itu akan dikoreksi. Jika Anda tertarik, Anda dapat melihat kode fungsi stats_correct, hanya 10 baris, dan saya tidak memahaminya bahkan setelah membacanya beberapa kali.

Periksa lagi catatan komit kode, mungkin ada sesuatu, tetapi hanya baris berikut, dan tidak mengerti:

remove calibration & improve CO correction

Di bawah Tucao, jika catatan pengiriman sedikit lebih detail, tanpa singkatan, atau menambahkan komentar kode, Anda dapat menghemat banyak hal.

Masalah telah diperiksa di sini, dan dapat dikonfirmasi bahwa ini bukan masalah produk, dan solusinya sudah ada, yaitu mengomentari kode koreksi di atas. Tetapi pasti ada alasan mengapa penulis wrk sengaja menambahkannya, dan tidak memahami alasannya selalu menjadi masalah tersembunyi. Secara alami, saya harus membuka issue untuk bertanya kepada penulis, dan wg, yang muncul sekali setahun, memberikan balasan 15 hari kemudian, dan ternyata singkatan CO dalam info komit di atas merujuk pada Coordinated Omission, dan memberikan artikel khusus tentang masalah ini, siswa yang tertarik dapat menggunakan kata kunci ini untuk mencari sendiri.

Secara singkat, Coordinated Omission berarti bahwa saat melakukan pengujian stres, tidak cukup hanya menghitung waktu antara mengirim dan menerima balasan, ini merujuk pada service time, yang akan melewatkan banyak masalah potensial, dan waktu tunggu permintaan pengujian juga perlu dihitung, agar dianggap sebagai response time yang menjadi perhatian pengguna.

Gil Tene, yang mengusulkan masalah CO, juga membuat modifikasi pada wrk untuk secara khusus menangani masalah CO: https://github.com/giltene/wrk2, dan README untuk proyek ini memiliki beberapa penjelasan tentang hal ini, yang dapat Anda baca jika tertarik, jadi saya tidak akan menyebutkannya di sini.

Untuk produk kami sendiri, tentu tidak ada penyumbatan dalam kode, dan saat melakukan pengujian stres, CPU berjalan penuh. Bahkan jika ada penyumbatan, ada flame chart untuk mengambil sampel dan menganalisis. Jadi koreksi sederhana dan kasar yang dilakukan wrk di sini untuk Coordinated Omission agak menyesatkan.