Geçen ay kendi yönetim toplantımızda oturuyordum. Ekranda, kampanya dönemi öncesi dışarıya yaptırılmış bir yük testi raporu vardı: rengârenk grafikler, kalabalık tablolar ve ortada kocaman bir cümle — "Ortalama yanıt süresi 180 ms." Masadaki herkes rahatlamıştı, kampanya tarihi çoktan kesinleşmişti. Ben raporun altlarında bir yerde duran tek bir hücreyi işaret ettim: p99 kolonunda 9,4 saniye yazıyordu. Toplantının havası bir anda değişti.
Açık konuşayım: yük testi yaptırmak işin kolay kısmı. k6 kurulur, JMeter kurulur, senaryo yazılır, rapor gelir. Asıl mesele o raporun karşısına geçip "bu sistem yayına hazır mı" sorusuna dürüst bir cevap verebilmek. 2010'dan beri irili ufaklı yüzlerce sistemin testinde bulundum ve şunu net gördüm: raporu okuyamamak, testi hiç yapmamamakla aşağı yukarı aynı riski taşıyor. Hatta bir açıdan daha tehlikeli — çünkü elinizde rapor olunca kendinizi güvende sanıyorsunuz. Yanlış okunan rapor, hiç okunmayan rapordan daha çok sistem batırmıştır.
Ortalama neden tatlı dilli bir yalancıdır
Basit bir örnekle başlayayım. Diyelim 100 istek attınız: 99'u 100 milisaniyede döndü, 1 tanesi 30 saniyelik timeout'a takıldı. Ortalamanız 400 ms civarına fırlar; medyan (yani p50) ise kılını kıpırdatmaz, 100 ms'de kalır. Tersi de olur: ortalama gayet masum görünürken kuyrukta ciddi bir sorun sessizce birikiyor olabilir. Tek bir sayıya bakarak bu iki dünyayı birbirinden ayırt etmeniz mümkün değil.
Bu yüzden bir raporu elimize aldığımızda ilk baktığımız şey yüzdelik dilimlerdir. p50 size tipik kullanıcının hikâyesini anlatır; p95 ve p99 ise en kötü deneyimleri. "p95 = 800 ms" cümlesinin Türkçesi şudur: her 100 isteğin 5'i, 800 milisaniyeden uzun sürüyor. Günde 100 bin istek alan bir sistemde bu, günde 5.000 kötü deneyim demek. Ve işin acı tarafı, o 5.000 deneyimin sahipleri rastgele dağılmaz — yavaşlık en çok yoğun saatlerde yaşandığı için, mağdurlar genellikle en değerli anda gelen müşterilerdir. Sepetini bırakıp giden de onlardır.
Peki neden p99'la yetinmiyoruz da bazen p999'a bakıyoruz? Ölçek meselesi. Günde bir milyon istek işleyen bir API'de p99'un dışında kalan yüzde birlik dilim, 10.000 istek demektir. "Yüzde bir" kulağa ihmal edilebilir gelir; "günde on bin mağdur" gelmez. Trafik büyüdükçe kuyruğun derinliklerine bakma zorunluluğunuz da büyür.
Pratik bir ipucu: ortalama ile medyan arasındaki makas açıldıysa, kuyruk probleminiz var demektir. O makas, raporun size çaktığı işaret fişeğidir; görmezden gelmeyin.
"Saniyede 2.000 istek kaldırıyoruz" cümlesinin eksik yarısı
Yıllar içinde sunumlarda çok duyduğum bir övünç kalıbı var: "Sistemimiz saniyede 2.000 istek işliyor." Her seferinde aynı soruyu soruyorum: peki o 2.000 istek/saniye anında p99 kaçtı? Çünkü throughput, gecikmeyle birlikte okunmadığında neredeyse hiçbir şey söylemez. Yarısı hata dönen, kalanı 15 saniyede cevap veren bir sistem de kâğıt üstünde "2.000 istek/saniye işliyor" olabilir.
Doğru okuma şekli şu: yük kademe kademe artarken gecikme eğrisi nerede kırılıyor? Sağlıklı bir sistemde gecikme, belli bir yüke kadar neredeyse düz bir plato çizer; sonra bir noktada eğri dikleşir. Literatürde "knee" denen o kırılma noktası, sisteminizin gerçek kapasitesidir. Kapasite planlaması tepe değere göre değil, kırılmadan önceki güvenli platoya göre yapılır. Bizim ekipte ölçü hep aynı: beklenen tepe trafik, kırılma noktasının en fazla üçte ikisinde kalsın. Kampanya geceleri sürprizleri hiç sevmez.
Bir de şu var: kırılma noktasını raporda göremiyorsanız, test muhtemelen yeterince yük basmamıştır. "Sistem hedef trafiği kaldırdı" demek güzel; ama sistemin nerede pes ettiğini bilmiyorsanız, elinizdeki güvenlik payının kaç santim olduğunu da bilmiyorsunuz demektir. Testin amacı sistemi övmek değil, sınırını bulmaktır.
Gecikme grafiği düzeliyorsa hemen sevinmeyin
Kaç kere gördük: yük artıyor, gecikme grafiği bir süre yükseliyor, sonra birden düşmeye başlıyor. Deneyimsiz göz bunu "sistem ısındı, toparladı" diye okur. Gerçek çoğu zaman tam tersidir — sistem cevap vermeyi bırakmış, hata dönmeye başlamıştır. Bir 500 hatası üretmek, gerçek bir işlemi tamamlamaktan çok daha ucuzdur; o yüzden çöken sistemin gecikme grafiği paradoksal biçimde güzelleşir. Yıllar önce bir testte tam bu deseni yakalamıştık: p95 aniden 2 saniyeden 300 milisaniyeye inmişti, çünkü uygulama sunucusu bağlantı havuzu tükenince istekleri anında reddetmeye başlamıştı. Grafik mutluydu; sistem ölüydü.
Bunun panzehiri basit bir disiplin: gecikme, throughput ve hata oranı her zaman aynı grafikte, aynı zaman ekseninde okunur. Üçünü ayrı sayfalara basan rapor, hikâyenin bağlamını koparır. Hata oranına özellikle plato bölgesinde bakın — sıfıra yakın seyretmesi gerekir; yükle birlikte tırmanıyorsa, kapasiteye ulaşmadan çok önce bir zayıf halkanız var demektir.
Timeout'ların tetiklediği retry fırtınalarını da unutmayın. İstemci tarafı her başarısız isteği üç kez tekrarlıyorsa, sıkışan sistemin üzerine gerçekte raporda görünenin üç katı yük biner — yani tam da en zayıf anında. Yük testi senaryonuz istemci retry davranışını taklit etmiyorsa, üretimdeki en kötü günü hiç test etmemişsiniz demektir.
Raporu kapatmadan önce sorduğumuz dört soru
Yıllar içinde kendi karar sürecimizi dört soruya indirdik. Bir raporun sonunda bu dördüne dürüstçe cevap verebiliyorsak, gerisi detaydır:
- Hedef trafikte p95 ve p99, taahhüt ettiğimiz SLA'in içinde mi?
- Kırılma noktası, beklenen tepe trafiğin en az 1,5 katı ötesinde mi?
- Hata oranı plato boyunca sıfıra yakın mı, yoksa yükle birlikte tırmanıyor mu?
- Kaynak grafikleri (CPU, bellek, bağlantı havuzu) doygunluktan uzak mı ve uzun soluklu soak koşusunda sızıntı eğilimi var mı?
Dördüncü soru üzerine bir not düşeyim, çünkü en çok atlanan o: yarım saatlik yük testi size ancak yarım saatlik gerçeği söyler. Bellek sızıntıları, dolmayan bağlantı havuzları ve şişen kuyruklar kendilerini saatler içinde gösterir. Yayın öncesi en az bir kez, orta seviye yükte 4-8 saatlik bir soak testi koşmadan "hazırız" demeyi bıraktık — bir araç takip projemizde tam altıncı saatte ortaya çıkan bir bellek sızıntısı, bize bu dersi kalıcı olarak öğretmişti. (O gün yayına çıksaydık, sızıntı üretimde gece yarısı patlayacaktı ve nöbetçi arkadaş o geceyi hiç unutmayacaktı.)
Dört soruya da gönül rahatlığıyla "evet" diyorsanız yayına çıkın. Diyemiyorsanız üzülmeyin; rapor size tam olarak nereye bakacağınızı söylüyor. Testin amacı da zaten buydu — kötü haberi üretimden önce, kontrollü bir ortamda almak. Elinizdeki rapora bu dört soruyu sorun; cevap alamadığınız her soru, testin eksik kaldığı yerdir. Bu grafiklerin dilini konuşmayı severim; iletişim sayfası açık.