Coordinated omission: yük testi neden yanlışlıkla "geçti" der?
Bir yük testinde p95 hedefin altında, hata oranı sıfır ve eşiklerin hepsi yeşil olabilir; sistem yine de istenen yükü kaldıramıyor olabilir. Bunun en yaygın nedeni coordinated omission'dır: sistem yavaşladığında yük üreticisi de onunla birlikte yavaşlar ve en kötü anlarda gönderilmesi gereken istekler hiç gönderilmez, dolayısıyla hiç ölçülmez. Bu rehber sorunun nasıl oluştuğunu, gerçek bir koşuda nasıl göründüğünü ve testin buna karşı nasıl kurulacağını anlatıyor.
Kapalı model: yavaşlayan sistem yükü kendi düşürür
Sabit sayıda sanal kullanıcıyla (VU) yapılan testte her VU bir iterasyonu bitirince yenisine başlar. Sistem hızlıyken çok iterasyon, yavaşken az iterasyon başlar. Yani hedef ne kadar yavaşlarsa üzerine o kadar az yük biner. Gerçek kullanıcılar böyle davranmaz: siteniz yavaşladı diye yeni ziyaretçiler gelmeyi bırakmaz.
Uydurma bir örnek. 100 VU, iterasyon normalde 100 ms sürüyor: saniyede 1000 iterasyon. Sistem 10 saniyeliğine 1 saniyeye yavaşlıyor. Bu 10 saniyede test saniyede yalnızca 100 iterasyon gönderir; normal trafikte gelecek olan yaklaşık 9000 iterasyon hiç gönderilmez. Ölçülen 1000 yavaş isteğin karşısında koşunun geri kalanındaki on binlerce hızlı istek durur ve p95 hâlâ hedefin altında görünebilir. Gerçek kullanıcıların o 10 saniyede yaşadığı bekleme rapora girmez.
Kapalı model "aynı anda N kullanıcı" sorusu için doğru araçtır; "saniyede N istek kaldırır mı" sorusu için yanıltır. Hangi sorunun hangi testle cevaplandığı: yük testi türleri.
Açık model: iterasyonlar zaman çizelgesiyle başlar
Açık modelde (Spitfire'da Sabit varış hızı ve Artan varış hızı, constant-arrival-rate ve ramping-arrival-rate) iterasyonlar hedef ne kadar yavaş olursa olsun saniyede belirlenen sayıda başlar. Yavaş yanıtlar ölçülür, yük düşmez. Ancak her iterasyonu yürütecek boş bir VU gerekir. Hedef yavaşladıkça daha çok VU yanıt beklerken meşgul kalır; Max VU sınırına gelindiğinde başlayamayan iterasyonlar düşer (dropped_iterations). Kuyruğa alınmazlar, sayılırlar.
Gereken VU sayısı yaklaşık saniyedeki iterasyon × bir iterasyonun saniye cinsinden süresidir (Little yasası). Saniyede 200 iterasyon ve iterasyon başına 1,5 saniye için yaklaşık 300 VU gerekir; hedef yavaşladığında daha fazlası. Max VU'yu bu sayının iki üç katında tutun.
Gerçek bir koşu: p95 eşiği geçti, sistem doymuştu
Açık modelde de VU tavanı gecikmeyi gizleyebilir. Örnek rapordaki koşu bunu gösteriyor: artan varış hızı, en çok 100 VU, iterasyon başına 2 istek, eşikler p95 < 800 ms ve hata oranı < %2.
- Saniyede 50, 100 ve 150 istekte p95 birkaç on milisaniye.
- 5×'te hedef saniyede 125 iterasyon (250 istek); oraya çıkarken servis saniyede yaklaşık 228 istekte doydu. p95 432 ms, p99 441 ms, hata %0.
- 100 VU / saniyede ~114 iterasyon ≈ iterasyon başına 0,88 saniye ≈ istek başına ~440 ms. Gecikme sistemin gerçek sınırını değil, aynı anda bekleyebilen VU sayısını yansıtıyor: 1000 VU ile aynı servis daha uzun kuyruklar ve çok daha yüksek bir p95 gösterirdi.
Yalnızca p95 ve hata oranına bakılsaydı bu koşu "geçti" olurdu: 432 ms, 800 ms'nin çok altında ve hata yok. Koşuyu doğru okuyan şey üçüncü eşikti: gönderilemeyen iterasyonlar 200'ü geçince koşu 8. dakikada durdu ve rapor nedenini yazdı.
Teste karşı nasıl korunursunuz
- Kapasite ve gecikme hedefleri için açık model kullanın. "Saniyede 500 istek, p95 300 ms" gibi bir hedef varış hızıyla test edilir.
- Düşen iterasyonu eşiğe bağlayın.
dropped_iterationsiçincount<1, yükün istediğiniz yük olduğunu garanti eder. Koşu sayfası düşen iterasyonları "N dropped" olarak gösterir. - Hedef hızla gerçekleşen hızı karşılaştırın. Saniyedeki istek hedefin altında kalıyorsa gecikme rakamları eksik bir resmi anlatıyordur.
- Max VU'yu cömert tutun. Düşen iterasyon gördüğünüzde önce Max VU'yu artırın; düşme sürüyor ve gecikme yükseliyorsa sistem sınırına yaklaşmıştır. O sınırı sayıyla bulmak için: kırılma noktası testi.
"thresholds": [
{ "metric": "req_duration", "expr": "p(95)<800" },
{ "metric": "req_failed", "expr": "rate<0.02" },
{ "metric": "dropped_iterations", "expr": "count<1" }
]Bu üç eşik birlikte okunur: p95 gecikmeyi, hata oranı doğruluğu, düşen iterasyon da gecikmenin istenen yükte ölçüldüğünü söyler. Yüzdeliklerin nasıl okunduğu: p95 ve p99 nedir?
Spitfire tek komutla Docker'a ya da Kubernetes'e kurulur; ücretsiz sürümde bütün test özellikleri ve protokoller açıktır.