Yük testi çoğu ekipte iki uçta yapılır: ya hiç yapılmaz ya da “kaç RPS gördük?” yarışına döner. Oysa operasyonel gerçeklik şudur: üretimde kazanmanız gereken şey maksimum throughput değil, SLO içinde kalabilmektir. Bu yüzden yük testini şu soruya bağlarım:
Bu servis, hedef SLO’sunu (latency + error) bozmadan hangi yükte kalabiliyor?
1) Önce SLO’yu netleştir
Yük testini başlatmadan şu üç hedefi yazın:
- p95 latency (ör. 250ms)
- error rate (ör. %0.5)
- test süresi boyunca “saturation sinyali” (CPU, thread pool, DB conn, queue lag…)
2) k6 senaryosu: Basit ama karar üreten
Örnek bir k6 iskeleti (HTTP API varsayalım):
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 20 },
{ duration: '3m', target: 50 },
{ duration: '3m', target: 80 },
{ duration: '2m', target: 0 },
],
thresholds: {
http_req_failed: ['rate<0.005'], // error rate < %0.5
http_req_duration: ['p(95)<250'], // p95 < 250ms
},
};
export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/v1/health`);
check(res, { 'status 200': (r) => r.status === 200 });
sleep(0.2);
}Bu senaryonun amacı “en çok istek” değil; SLO içinde kalma sınırını gözlemek.
3) Kapasite baseline: “bugün” ile “yarın”ı kıyasla
Operasyonel fayda için test tek seferlik olmamalı. İki pratik yöntem:
- Baseline’ı JSON olarak saklayın (örn. son başarılı release)
- Yeni test sonucunu baseline ile kıyaslayıp “regression” yakalayın
Basit bir yaklaşım:
- k6 çıktısını
--summary-exportile JSON’a alın - CI içinde, p95 ve error metriklerini baseline ile kıyaslayın
- Belirli bir sapma üstünde pipeline’ı fail edin
4) Release gate mantığı: performans bir “kabul kapısı” olsun
Benim önerdiğim release gate kuralı:
- Fonksiyonel testler geçse bile,
- Eğer p95 veya error rate SLO’yu aşıyorsa ya da baseline’dan belirgin kötüleşiyorsa,
- Release “guarded” moda düşer (daha küçük canary, daha agresif rollback, daha kısa gözlem aralığı).
Bu model “performans testini” bir rapor olmaktan çıkarıp değişiklik kontrolüne bağlar.
5) Sahada en sık hata: Test ortamı gerçeği yansıtmaz
Bu tuzağı azaltmak için:
- Üretim benzeri veri (en azından veri boyutu ve indeks davranışı)
- Cache warmup ayrı; ölçümü warmup sonrası yapın
- Test kullanıcılarının rate limit / auth etkisini simüle edin
- Downstream bağımlılıkları “fake” ile değil, kontrollü gerçekle test edin
Sonuç: Yük testi, kapasite yönetiminin dili olmalı
k6 ile SLO odaklı yük testi, performansı bir “hava durumu” değil, operasyonel karar girdisi yapar. Baseline + gate birlikte çalıştığında “yavaşlayan release”leri daha üretime çıkmadan yakalarsınız. Bu da incident yerine kontrollü iyileştirme üretir.