Access log'dan yük testi: gerçek trafiği test ortamında yeniden oynatmak

Albiferro Yazılım ve Sistem Limited Şirketi · Yayın 7 Kasım 2026

Ayrıntılı dokümantasyon →

Elle yazılmış bir yük testi, kullanıcıların gerçekte hangi endpoint'lere ne sıklıkla geldiğini tahmin eder. Spitfire bir erişim logundan ya da trace dosyasından bu karışımı ve gün içindeki eğriyi çıkarır, her endpoint'i gözlenen hızıyla süren bir test üretir. Bu sayfa dosyanın hazırlanmasını, okunmasını ve üretilen testin test ortamına yönlendirilmesini adım adım anlatıyor.

Hangi dosyalar okunur?

Dosya en çok 512 MB olabilir. Biçim kendiliğinden algılanır ya da elle seçilir:

1. Dosyayı hazırlayın

Yoğun bir günün logunu seçin; sonra pencereyi Spitfire'da daraltırsınız. Komutlar log dosyasını ev klasörünüze tek dosya olarak yazar.

nginx (döndürülmüş ve sıkıştırılmış dosyalar dahil)

AWS ALB

BUCKET, HESAP ve BOLGE'yi load balancer'ınızın log ayarındaki değerlerle, tarihi kendi gününüzle değiştirin.

2. Dosyayı okutun

1. Testler → Gerçek trafikten'e tıklayın.
2. Log ya da trace dosyası seçin; Biçim'i Biçimi algıla'da bırakın.
3. Oku'ya basın. Özet N kayıttan M istek yazar; okunamayan kayıtlar ve okunurken atılan gizli değerler ayrıca sayılır.

Başarı kontrolü: istek sayısı kayıt sayısına yakınsa biçim doğru okunmuştur. İstek sayısı sıfır ya da çok düşükse Biçim'i elle seçip yeniden okutun.

3. Zaman penceresini ve karışımı seçin

1. Zaman penceresi: Başlangıç ve Bitiş'i seçin ya da En yoğun saat / Tüm dosya'ya basın.
2. Endpoint karışımı tablosunu inceleyin. Yollar normalleştirilir: /orders/123 → /orders/:id; UUID'ler, özetler, tarihler, opak token'lar ve 20 ya da daha çok farklı değeri olan yol parçaları parametre olur.

4. Testi test ortamına yönlendirin

1. Temel URL: logdaki sunucu önerilir; buraya test ortamınızın adresini yazın. Testte {{base}} olur.
2. Ölçek çarpanı: 0,01–100. 1 gözlenen trafik, 2 iki katı, 0,1 onda biri. Küçük bir test ortamında düşük başlayın.
3. Testteki endpoint: varsayılan 20, en çok 50; en sık gelenler alınır, gerisi dışarıda kalır.
4. Testin yapacağı özetini okuyun (kapsama oranı, aşama süresi, tepe hızı) ve Testi oluştur'a basın. Veri değiştiren endpoint'ler (POST, PUT, DELETE) API dokümanı içe aktarmadaki gibi ayrıca onaylanır.

Her endpoint, aşamaları kendi gözlenen hızını izleyen bir ramping-arrival-rate senaryosu olur; senaryolar birlikte karışımı ve eğriyi yeniden oynatır. Bu açık bir yük modelidir: sistem yavaşlasa da istekler logdaki hızla gelmeye devam eder (yük testi türleri ve yük modelleri).

5. Body, header ve kimlik bilgilerini ekleyin

Erişim loglarında request body ve header yoktur. Testi editörde açın; POST ve PUT adımlarına body'leri, gerekiyorsa bir giriş adımı ve Authorization header'ını ekleyin. Yol parametreleri (:id) için test ortamında gerçekten bulunan değerleri bir veri dosyasından verin.

Başarı kontrolü: Dene ile tek VU'luk bir deneme yapın; adımların hepsi 2xx dönmelidir. 404 görürseniz genellikle temel URL hâlâ üretimi gösteriyordur ya da yol parametrelerinin test ortamında karşılığı yoktur.

Gizlilik

• Dosya satır satır okunur ve saklanmaz.
• Controller belleğinde en çok bir saat yalnızca türetilmiş değerler kalır (zaman, yöntem, yol şablonu, durum, gecikme); test oluşunca silinir.
• İstemci adresleri, kullanıcılar, tarayıcı bilgisi ve header'lar hiç okunmaz.
• Gizli görünen sorgu değerleri ve yol parçaları (token, parola, oturum kimliği, e-posta) okunurken atılır.

Sık sorulan sorular