Koordineli atlama: kapalı döngü yük testleri p99 gecikmenizi neden olduğundan düşük gösterir

dev.to'da yakın zamanda yayımlanan bir yazı, çoğu yük testi aracının ürettiği yüzdelik değerlerin kuyruk gecikmesini neden sistematik olarak olduğundan düşük gösterdiğini açıklıyor. Bu olgu koordineli atlama (coordinated omission) olarak adlandırılıyor ve yazıya göre, yük testinde 12 ms p99 raporlayan bir servisin gerçek kullanıcılar için çok saniyelik takılmalar yaşamasına yol açabiliyor — aynı yüzdelik matematiğiyle kurulan gösterge panelleri ise sağlıklı görünmeye devam ediyor.

Yanlılık nasıl işliyor

Çoğu yük üreteci kapalı döngü olarak çalışır: bir istek gönder, yanıtı bekle, gecikmeyi kaydet, sonra bir sonrakini gönder. Yazı, ab, deneyimsiz wrk scriptleri ve birçok ev yapımı test düzeneğinin varsayılan olarak bu şekilde çalıştığına dikkat çekiyor. Bu, sadık bir ölçüm gibi hissettirir; çünkü kaydedilen her örnek, gerçek bir isteğin gerçek süresidir.

Sorun sistem takıldığında ortaya çıkar — bir garbage-collection duraklaması, bir lock çekişmesi spike'ı veya bir downstream timeout. Yazıdaki örnekte, saniyede 100 istek hedefleyen kapalı döngü bir üreteç bir saniyelik bir takılmayla karşılaşır. O saniye boyunca havada tam olarak bir isteği vardır; o istek 1000 ms sonra döner ve tek bir kötü örnek olur. Ancak saniyede 100 istekle akan gerçek trafik, aynı aralıkta yaklaşık 100 istek gönderirdi; hepsi takılan isteğin arkasında kuyruğa girer ve her biri neredeyse tam bir saniyelik gecikme yaşardı. Üreteç bu istekleri hiç göndermez çünkü yanıt beklerken bloke olmuştur; dolayısıyla bu istekler yüzdelik hesabına hiç girmez.

Atlamanın koordineli olan kısmı budur: eksik örnekler tam da gecikmenin en kötü olduğu anda kaybolur — yani bir p99'un tanımlamak için var olduğu bölgenin tam ortasında.

Çarpıtmanın boyutu

dev.to yazısına göre terim, HdrHistogram'ın yaratıcısı olan Azul Systems'ten Gil Tene'den geliyor; Tene terimi ilk olarak garbage collection etkisini yanlış gösteren JVM duraklama ölçüm araçlarına uygulamış. Kavram, herhangi bir sistemin herhangi bir kapalı döngü benchmark'ına genellenir: HTTP API'leri, veritabanları, kuyruklar ve çıkarım (inference) uç noktaları.

Boyut küçük bir yuvarlama hatası değil. Yazı, yüzdelikleri varış hızı temelinde yeniden hesaplamanın — fiilen atlanan istekleri hesaba katmanın — raporlanan tek haneli milisaniyelik bir p99'u rutin olarak birkaç yüz milisaniyeye, hatta bir tam saniyeye dönüştürdüğünü bildiriyor. Gerçek kuyruk, rapordaki rakamdan kabaca on kat kötü olabilir ve tam da kuyruk yüzdeliklerinin ortaya çıkarmak için tasarlandığı dağılımın o bölümünde yoğunlaşır.

Ne yapmalı

Yazı üç düzeltme öneriyor.

Birincisi, açık döngü veya düzeltilmiş bir yük üreteci kullanın. wrk2, arrival-rate executor'lı k6, Gatling ve Locust'un sabit varış hızı (constant-arrival-rate) şekli gibi araçlar, önceki istekler dönmüş olsun ya da olmasın istekleri sabit bir zamanlamayla gönderir; bu da üretim istemcilerinin davranışını yansıtır — gerçek kullanıcılar en yavaş isteğinizin arkasında kuyruğa girmez.

İkincisi, araç değiştirmek pratik değilse, her isteğin gönderilmesi gereken zamanı ile fiilen gönderildiği zamanı kaydedin ve yüzdelikleri bu farktan düzeltilmiş şekilde hesaplayın. HdrHistogram bu tür koordineli atlama düzeltmesi için yerleşik yöntemler içerir.

Üçüncüsü, her kapalı döngü yüzdeliğini bir alt sınır olarak yeniden yorumlayın. 12 ms p99 raporlayan bir test, p99'un ideal, takılmasız koşullarda en az 12 ms olduğunu destekler — p99'un 12 ms olduğunu değil. Bu yeniden çerçeveleme bile, geçen bir yük testinin lansmandan önce ne kadar güven hak ettiğini değiştirir.

Neden önemli

Yazı, sorunun LLM destekli servisler için azalmak yerine daha da keskinleştiğini savunuyor. Çıkarım uç noktalarında istek başına gecikme son derece değişkendir — cache hit'e karşı cold start, kısa üretimlere karşı uzun üretimler — bu yüzden takılmalar istisnai değil, sık yaşanır. Böyle bir sistem üzerindeki kapalı döngü bir yük testi, en çok görmeniz gereken anda en kötü davranışı aktif olarak gizler. Yük testi yüzdeliklerini sürüm kapısı olarak kullanan her ekip için pratik çıkarım şudur: aracın gecikmeyi sabit bir varış hızında ölçüp ölçmediğini kontrol edin ve kapalı döngü p99 rakamlarını olgu değil, alt sınır olarak değerlendirin.