Mart ayında bir müşterimiz kampanya sabahı saat 10'da aradı; site çökmüştü. İşin acı tarafı, iki hafta önce yaptırdıkları yük testi raporunun yemyeşil olmasıydı: "Sistem 2000 eşzamanlı kullanıcıyı sorunsuz taşır." Taşımadı. Rapor aslında yanlış da değildi — sadece yanlış soruların doğru cevabıydı. Danışmanlık için geldiğimiz projelerde bu tabloyu o kadar sık görüyoruz ki, yük testi yapmak ile doğru yük testi yapmak arasındaki farkı bir kere de buradan yazmak istedim. En pahalıya mal olan beş hata üzerinden gideceğim; beşi de gerçek projelerden.
Baştan bir not: bu yazıda araç tartışması yapmayacağım. JMeter, k6, Gatling, Locust — hepsiyle iyi test de yapılır, kötü test de. Kampanya gününü kurtaran şey aracın markası değil, senaryonun dürüstlüğüdür. Beş hatanın beşi de araçtan bağımsızdır; hangi aracı seviyorsanız onunla okuyun.
Ortalama, en tatlı yalancıdır
"Ortalama yanıt süresi 180 milisaniye" cümlesi kulağa harika gelir. Ama aynı sistemde kullanıcıların %5'i 4 saniye bekliyor olabilir ve ortalama bunu ustaca gizler. Yüz kişiden doksan beşi hızlı cevap alırken beşinin ekrana bakakalması, ortalamayı neredeyse hiç kıpırdatmaz.
Karar metriğiniz p95 ve p99 olmalı: kullanıcıların yüzde 95'inin ve 99'unun altında kaldığı yanıt süresi. SLA'larınızı da yüzdelikle yazın; "ortalama 200 ms" taahhüdü pratikte hiçbir şey taahhüt etmez. Şunu hep hatırlatırım: kuyruktaki o %5, istatistiksel bir ayrıntı değil — sepetini bırakıp giden gerçek müşterinizdir. Ve işin cilvesi, sistemin en yoğun olduğu anlarda kuyruğa düşenler genellikle en değerli trafiğinizdir.
Bu farkı yönetim katına taşımanın pratik bir yolu var: rapora "en yavaş yüzde beşin bekleme süresi" diye tek bir satır ekletin ve yanına o dilimin temsil ettiği aylık ciroyu yazdırın. Ortalamanın arkasına saklanma alışkanlığı, o satır tabloya girdiği ay kendiliğinden biter. Denedik, biliyoruz.
Staging'de ölçüp üretim adına konuşmak
Yarı kapasiteli bir staging ortamında test yapıp sonucu ikiyle çarpmak mühendislik değil, fal bakmaktır. Performans doğrusal ölçeklenmez; bağlantı havuzları, önbellek boyutları, disk hızları farklıysa sistemin kırılma noktası bambaşka bir yerdedir.
İki dürüst seçenek var. Ya üretim eşleniği bir ortam kurarsınız — bulut çağında bunu test süresince kiralayıp sonra kapatmak eskisi kadar pahalı değil — ya da farkları tek tek belgeleyip sonuçları yalnızca "alt sınır" olarak okursunuz. "Staging bu kadar taşıdıysa üretim iki katını taşır" cümlesi rapora girdiği an, rapor masal olmuştur.
Veri hacmi de ortamın parçasıdır, bunu atlamayın. 10 bin kayıtlık tabloyla yapılan test, 10 milyon kayıtlık üretim tablosunun davranışı hakkında neredeyse hiçbir şey söylemez. Sorgu planları değişir, indeksler belleğe sığmaz olur, o masum LIKE sorgusu canavara döner. Üretim ölçeğinde doldurulmamış veritabanıyla koşulan her senaryo eksiktir.
"O kadar veriyi nereden bulalım?" diye soran olacak. İki yol var: üretim verisini maskeleyerek (kişisel alanları anonimleştirerek — KVKK'yı testte de unutmuyoruz) kopyalamak, ya da üretimin istatistiksel dağılımını taklit eden sentetik veri üretmek. İkisi de birkaç günlük iş; "üretimde sürpriz" ile kıyaslanınca bedava sayılır.
Soğuk sistemden ölçüm almak (ya da tam tersi)
Testin ilk dakikalarında cache boştur, bağlantı havuzları soğuktur. Oradan alınan ölçüm karamsar yalan söyler; paniğe kapılır, gerek olmayan optimizasyona koşarsınız. Isınma süresini ölçümün dışında tutun, sayaçları sistem oturduktan sonra başlatın.
Madalyonun öbür yüzü daha sinsi. Senaryonuzda bütün sanal kullanıcılar aynı üç ürünü çağırıyorsa, cache hit oranınız suni şekilde şişer ve bu sefer rapor iyimser yalan söyler. Gerçek hayatta bin kullanıcı bin farklı sayfaya dağılır, cache çok daha az yardım eder. Bir müşterimizdeki "testte 50 ms, üretimde 800 ms" bilmecesinin cevabı tam buydu: test verisinde çeşitlilik yoktu. Gerçekçi dağılım — popüler ürünlerde yoğunlaşan, uzun kuyruğa yayılan — senaryonun olmazsa olmazı.
Sadece güneşli günü prova etmek
Klasik yük testi "1000 kullanıcıda ne olur?" sorusunu cevaplar. Ama üretimde sizi yere seren soru çoğunlukla başkadır: "Bir bileşen yavaşlarsa ne olur?"
Ödeme sağlayıcınız 5 saniye gecikmeye başladığında thread havuzunuz doluyor mu? Doluyorsa, ödemeyle hiç ilgisi olmayan sayfalar dahil bütün site kilitleniyor mu? (Çoğu sistemde cevap evet — ve bunu ilk kez kampanya günü öğrenmek çok acı.) Timeout değerleriniz gerçekçi mi? Circuit breaker'larınız devreye girip yaralı bileşeni izole edebiliyor mu? Veritabanı replikası düştüğünde okuma trafiği nereye gidiyor?
Bu sorulara cevabı olmayan test, testin yarısıdır. Yük aracınızın yanına, bağımlılıkları kasıtlı yavaşlatan basit bir kaos katmanı ekleyin; en ilkel haliyle bile mimarinizin zayıf eklemlerini gösterecektir.
On dakika koşup sekiz saatlik geceye hüküm vermek
Kısa testler ani sorunları yakalar; yavaş sızıntıları asla. Bellek sızıntısı, kapanmayan bağlantılar, şişen log dosyaları, sessizce dolan diskler — hepsi saatler içinde birikir. 10 dakikalık koşuda her şey pırıl pırıldır; sistem altıncı saatte, gece yarısı devrilir.
Büyük sürümlerden önce en az 4-8 saatlik sabit yük (soak testi) koşmayı standart haline getirin. Sonra grafiklere bakın: yük sabitken yavaş yavaş tırmanan her çizgi — bellek, açık bağlantı sayısı, yanıt süresi, fark etmez — önceden yazılmış bir arıza duyurusudur. Soak testinin sıkıcılığı bir kusur değil, özelliğidir; heyecanlı geçen soak testi kötü haberdir.
Beş hatanın dışında ama hepsiyle akraba bir konu daha: senaryo gerçekçiliği. Gerçek kullanıcı sayfalar arasında düşünür, durur, geri döner, sekmeyi açık unutur. Aralıksız istek yağdıran sanal kullanıcı, gerçek hayatta karşılığı olmayan bir yük profili üretir — bazen olduğundan kötü, bazen olduğundan iyi bir tablo çizer, ikisi de zararlıdır. Senaryolarınıza düşünme süreleri (think time) koyun; gezinme, arama ve satın alma oranlarını tahminle değil, kendi analitik verinizden alın. Testin amacı sistemi matematiksel olarak ezmek değil, kampanya gününün sadık bir provasını yapmaktır.
Baştaki müşterimize döneyim. Çökme sonrası analizde beş hatanın üçü birden karşımıza çıktı: ortalamaya bakılmış, küçük veriyle test edilmiş, ödeme sağlayıcısının yavaşlaması hiç denenmemişti. Kampanya günü gerçekleşen senaryo tam da oydu. Bir sonraki kampanyaya bu maddeleri düzelterek girdik; sistem gün boyu p95 hedefinin altında kaldı ve telefonum hiç çalmadı. Benim için başarılı projenin tanımı budur: çalmayan telefon. Elinizdeki test raporunun yeşil mi yoksa anlamlı mı olduğunu birlikte görmek isterseniz bize yazın; rapora bir çift yabancı göz her zaman iyi gelir.