Yük denemesine binlerce sanal kullanıcıyla başlamak, ölçümden önce yeni bir problem üretmenin kolay yoludur. Önce küçük bir deneyin hangi soruya cevap verdiğini tanımlarım. Arşivdeki k6 betiklerinden hareketle bu yazıda yalnız kendi yerel sağlık ucuna kısa, sınırlı bir kontrol kuruyorum; üretim kapasitesi iddiası üretmiyorum.
Bir sanal kullanıcı ne yapıyor?
Örnek beş saniye sürüyor ve tek VU kullanıyor. Her iterasyonda localhost üzerindeki /health çağrısı yapılıyor, ardından bir saniye bekleniyor. Bu yalnız sahip olduğun yerel uygulamayla denenmeli; hedef adresi rastgele dış sistemlere çevirmek deneyin amacı değil. Dosya k6 ile çalıştırılır, normal Node.js HTTP betiği değildir.
import http from 'k6/http';
import {check,sleep} from 'k6';
export const options={
vus:1,duration:'5s',
thresholds:{http_req_failed:['rate<0.01'],http_req_duration:['p(95)<500']}
};
export default function(){
const response=http.get('http://127.0.0.1:5237/health',{timeout:'2s'});
check(response,{'status is 200':r=>r.status===200});
sleep(1);
}sleep(1), saniyede tam bir istek sözleşmesi oluşturmaz. Bir turun süresi istek, kontrol ve beklemenin toplamına bağlı. Bu kısa deneyde yalnız az sayıda gözlem oluşur. VU sayısı eşzamanlı çalışan akış sayısıdır; tek başına sabit istek/saniye değeri değildir. Kapalı iş yükü modeli yavaşlayan yanıtlarla birlikte kendi üretim hızını da değiştirebilir.
Check ile threshold farklı sonuç üretir
check, yanıtın 200 olup olmadığını checks metriğine kaydeder. Threshold ise deneyin kabul koşulunu belirler ve başarısızlık çıkış koduna yansıyabilir. Örnekte http_req_failed ve http_req_duration için eşik var; checks metriği için yok. Bir check'in false olması tek başına her durumda test sürecini başarısız çıkış koduyla bitirmez.
Bütün kontrollerin geçmesini de zorunlu kılacaksam seçeneklere ayrı bir eşik eklerim. Aşağıdaki satır mevcut thresholds nesnesine eklenecek bir parçadır:
checks: ['rate==1']http_req_failed, k6'nın yanıtı başarılı sayma politikasına bağlı bir HTTP metriğidir; iş yanıtı içindeki success alanını kendiliğinden anlamaz. JSON iş sonucunu kontrol etmek gerekiyorsa bunun için ayrıca check yazılır. 200 dönen başarısız bir iş yanıtını yalnız HTTP hata oranıyla yakalayamam.
p95 ortalama değildir
p(95)<500, gözlenen istek süreleri için 95. yüzdeliğin 500 ms altında olmasını ister. Ortalama düşükken yavaş uçlar bulunabilir; yüzdelik bu kuyruğu görmeye yardımcı olur. Ama beş saniyelik, tek kullanıcılı birkaç gözlemden güvenilir üretim p95'i çıkarmam. Örnek eşiğin nasıl tanımlandığını öğretir, kapasite raporu yerine geçmez.
http_req_duration, bağlantı kurma ve TLS gibi her evreyi aynı anlamda kapsayan tek toplam değildir; ayrıntılı metriklerin ne ölçtüğüne bakarım. İstemcinin gördüğü uçtan uca süre ile belirli bir HTTP aşaması metriğini karşılaştırırken aynı ölçü birimi ve kapsamı kullanmak gerekir.
Health ucunun hızlı olması hangi sonucu verir?
Bir sağlık endpoint'i yalnız süreç cevap veriyor kontrolü yapabilir. Veritabanı sorgusu, giriş, dosya üretimi veya makale render süresi bu çağrıda olmayabilir. Health testi bağlantı ve deney düzeneğinin ilk kontrolüdür. Gerçek iş akışını ölçmek için temsili okuma/yazma, veri büyüklüğü ve kullanıcı davranışı gerekir; bunlar bu küçük betikte yok.
Sonucu tekrar üretilebilir kılmak
Uygulama sürümü, veri kümesi, makine kaynakları, başlangıç/ısınma durumu ve test seçenekleri kaydedilirse iki sonuç anlamlı biçimde karşılaştırılabilir. Aynı makinede hem yük üretici hem uygulama çalışınca kaynakları paylaştıklarını da hesaba katarım. Hata oranını veya yüzdelikleri raporlarken örnek sayısını saklamam.
Önce uygulama açıkken koşar, ardından kontrollü olarak erişilemeyen yerel uçla eşik başarısızlığını doğrularım. Testin yeşil olduğu kadar gerektiğinde kırmızı olabildiğini görmek de önemlidir. Üretim için uygun yük profili ancak bu temel sözleşme anlaşıldıktan sonra seçilir.