Mobil geliştirmede Load Test — nedir, senaryolar ve nasıl yapılır

Load Test Nedir?

Load Test, bir sistemin beklenen sayıda eşzamanlı istek veya kullanıcı altında nasıl performans gösterdiğini doğrulama sürecidir. Mobil geliştirme bağlamında Load Test, hem sunucu tarafına (API, veritabanı, önbellek) hem de istemci tarafına (push bildirimi işleme, veri senkronizasyonu) uygulanır. Stres testlerinden temel farkı, Load Test’in aşırı değil, gerçek yükü simüle etmesidir. AWS Well-Architected Framework (2024)’e göre, yük testleri gerçek kullanım analizlerine dayalı yük profilleri kullanılarak yapılmalıdır.

Load Test, API’ye HTTP istekleri, WebSocket bağlantıları veya veritabanı işlemleri düzeyinde gerçekleştirilebilir. Amaç, her isteğin yanıt süresinin belirtilen bir eşiği (genellikle API için 500–1000 ms) aşmamasını ve verimin (RPS — saniyedeki istek sayısı) gereksinimleri karşılamasını sağlamaktır. Google Cloud Armor (2024), yüzdeliklere dayalı eşik değerleri tanımlar: kritik uç noktalar için p95 yanıt süresi 2 saniyeyi aşmamalıdır.

Bir mobil backend’in yük testi, tipik senaryoların simülasyonunu içerir: kayıt, kimlik doğrulama, akış yükleme, form gönderme. Senaryolar, HAR dosyaları (HTTP Archive) olarak kaydedilir ve yük testi aracı tarafından yeniden oynatılır. k6 belgelerine (2025) göre, HAR dönüşümü Load Test hazırlık süresini %60 oranında azaltabilir.

Yük Testinin Hedefleri

Load Test’in ilk hedefi sistem verimini doğrulamaktır. Spesifikasyon 1000 RPS işleme gerektiriyorsa, yük testi bunu %20 marj ile doğrulamalıdır. Netflix Tech Blog (2024)’e göre, Netflix’te yük testleri tepe yükün 2 katı marj ile yapılır: 10000 RPS bekleniyorsa, test 20000 RPS’yi kontrol eder. Bu yaklaşım, ani trafik artışlarında kararlılığı garanti eder.

İkinci hedef, mimarideki darboğazları belirlemektir. Mobil backend’lerdeki tipik darboğazlar veritabanı (yavaş sorgular), önbellek (yanlış geçersiz kılma stratejisi) ve harici API’lerdir (yavaş üçüncü taraf hizmetler). Dağıtık izleme (Jaeger, Zipkin), sorunu belirli bir hizmet veya istek düzeyinde konumlandırmaya yardımcı olur.

Üçüncü hedef, doyum noktasını belirlemektir. Bu, yeni kullanıcılar eklemenin artık verimi artırmadığı andır. Mobil uygulamalarda doyum noktası genellikle veritabanı sunucularında CPU yükünün %70–80’inde gerçekleşir. Otomatik ölçeklendirme bu noktaya ulaşmadan önce devreye girmelidir.

Yük Testi Senaryoları

Ani yük testi (Spike Test) — sabah push bildirimi gönderimi veya reklam kampanyası başlatma gibi ani bir aktivite artışını simüle eder. Grafana k6 (2025)’e göre, Spike Test, 30 saniye içinde yükün 100’den 10000 RPS’ye yükselmesini simüle eder. Sistem, istek kaybetmeden ve yanıt süresini %50’den fazla aşmadan bunu yönetmelidir.

Dayanıklılık testi (Endurance Test) — yük altında uzun süreli çalışma sırasında sistem kararlılığını kontrol eder. Tipik süre 1–4 saattir. Endurance Test, sunucu uygulamalarında bellek sızıntılarını, veritabanı bağlantı havuzu sorunlarını ve önbellek performansı düşüşünü ortaya çıkarır. PostgreSQL bağlantı havuzu, uygun yapılandırma olmadan uzun süreli yük altında 2–3 saat içinde mevcut bağlantıları tüketebilir.

Kademeli yük testi (Step Load Test) — her 2–5 dakikada bir %10–20’lik adımlarla kademeli yük artışı. Bu senaryo, sistemin bozulmaya başladığı tam sınırı bulmaya yardımcı olur. InfluxDB ve Prometheus, yanıt süresi ile RPS arasında bir grafik oluşturmak için her adımda metrikleri toplar.

Load Test Metrikleri

Yanıt süresi

Yanıt süresi Load Test’in birincil metriğidir. Milisaniye cinsinden ölçülür ve yüzdeliklere göre analiz edilir: p50 (medyan), p95 ve p99. Google SRE (2024), REST API için p95 eşiğinin 1000 ms’yi, gRPC için 200 ms’yi aşmamasını önerir. Yüzdelikler ortalamalardan daha önemlidir çünkü kullanıcıların ilk fark ettiği en kötü isteklerin davranışını gösterirler. Apdex (Uygulama Performans İndeksi), memnun, toleranslı ve hayal kırıklığına uğramış kullanıcıların oranını dikkate alan bileşik bir metriktir.

Verim

Verim (Throughput) — birim zaman başına başarılı istek sayısı. RPS (saniyedeki istek sayısı) veya TPS (saniyedeki işlem sayısı) cinsinden ölçülür. “Zaman — RPS” koordinatlarındaki verim grafiği doyum noktasına kadar doğrusal olmalıdır. Artan yükle verimde keskin bir düşüş, sistem sınırına ulaşıldığının işaretidir. Apache Bench ve wrk, geliştirme sırasında hızlı verim kontrolleri için basit CLI araçlarıdır.

Hata oranı

Hata oranı (Error Rate) — toplam istek sayısına karşı HTTP durumu 4xx veya 5xx olan yanıtların oranı. Kabul edilebilir eşik %1’in altındadır. Yüksek yük altında 429 (Çok Fazla İstek) ve 503 (Hizmet Kullanılamıyor) hataları, hız sınırlaması ve otomatik ölçeklendirme yapılandırması gerektiğini gösterir. API Gateway tarafındaki bir hız sınırlayıcı, backend’i izin verilen yükün aşılmasına karşı korur. Üstel geri alma ile yeniden deneme politikası, istemcilerin geçici hataları doğru şekilde yönetmesine yardımcı olur.

Load Test İçin Araçlar

k6 (Grafana)

k6 — Grafana’nın lider açık kaynak yük testi aracı. Betikler JavaScript ile yazılır, modüler senaryoları, eşikleri (thresholds) ve Prometheus ve InfluxDB ile entegrasyonu destekler. k6 hem CLI’de hem de Grafana Cloud k6 bulutunda çalıştırılabilir. Grafana Cloud, Load Test sonuçlarından otomatik olarak panolar oluşturur ve bunları geçmiş verilerle karşılaştırır. k6, ayrı bir k6/net/grpc modülü aracılığıyla Protocol Buffers ve gRPC’yi destekler.

Apache JMeter

Apache JMeter — grafik arayüzlü klasik bir Load Test aracı. HTTP, JDBC, JMS, FTP ve TCP dahil geniş bir protokol yelpazesini destekler. JMeter, birçok farklı istek türü içeren karmaşık senaryolar için daha uygundur ancak k6’ya kıyasla daha fazla manuel yapılandırma gerektirir. JMeter Eklentileri, WebSocket ve gRPC testleri için işlevselliği genişletir. Dağıtık çalıştırma için JMeter, bir denetleyici ile ana-bağımlı mimari kullanır.

Locust

Locust — kod içinde yük senaryolarını tanımlamaya izin veren Python tabanlı bir araçtır. Locust, Python’u ana otomasyon dili olarak kullanan ekipler için kullanışlıdır. k6 ve JMeter’ın aksine, Locust kutudan çıktığı gibi dağıtık çalıştırmayı destekler: bir ana düğüm birkaç işçi düğümü koordine eder. Dağıtık çalıştırma, birden çok makineden 100000 RPS’ye kadar yük oluşturulmasına izin verir. Locust ayrıca özel uzantılar aracılığıyla WebSocket testlerini destekler.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

k6 ile Load Test Yazma Örneği

Yukarıda gösterilen k6 betiği, tipik bir yük testi yapısını gösterir. Options, yük profilini tanımlar: 2 dakika içinde 100 kullanıcıya ramp-up, ardından 5 dakika sabit yük ve tekrar 200 kullanıcıya ramp-up. Eşikler, test geçme kriterlerini tanımlar: p95 istek süresi 500 ms’yi aşmamalı, hata oranı %1’in altında olmalıdır. Eşikler aşılırsa, k6 sıfır olmayan bir kodla çıkar — bu, Load Test’in CI/CD’ye entegre edilmesini sağlar.

Mobil geliştirmede, sunucu tarafının Load Test’i, ek yük oluşturan yeni özellikler (beğeniler, yorumlar, akış) başlatılırken özellikle önemlidir. Öneri — üretime dağıtmadan önce her staging’de Load Test yapın. API tasarım aşamasında bir temel yük profili oluşturmak, sonraki aşamalarda mimari sorunları önlemeye yardımcı olur.