DEV Community

Cover image for wrk: Komut Satırından API Yük Testi Nasıl Yapılır
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

wrk: Komut Satırından API Yük Testi Nasıl Yapılır

Bir uç nokta yayınladınız. Tarayıcıda çalışıyor; ancak 400 eşzamanlı istek geldiğinde ne olacağını bilmiyorsunuz. Gecikme sabit mi kalacak, p99 patlayacak mı, servis saniyede 1.000 isteği kaldıracak mı yoksa 300 RPS civarında mı çökecek?

Apidog'u bugün deneyin

wrk bu sorulara hızlı yanıt verir. Belirli bir URL'ye yüksek hacimli HTTP trafiği gönderir ve sunucunun yük altında ne kadar hızlı yanıt verdiğini raporlar.

wrk Nedir ve Ne Zaman Kullanılır

wrk, modern bir HTTP performans ölçüm aracıdır. Tek bir çok çekirdekli makineden yük üretir; sunucunun gecikmesini, istek oranını ve aktarım miktarını ölçer.

Linux'ta epoll, macOS'ta kqueue kullanan ölçeklenebilir bir olay döngüsü ve çoklu iş parçacığı modeliyle çalışır. Bu nedenle tek bir makineden ciddi miktarda trafik üretebilir.

wrk şu sorular için uygundur:

  • Bu endpoint saniyede kaç isteği sürdürebiliyor?
  • Ortalama gecikme ile p90/p99 gecikme arasında ne kadar fark var?
  • Servis 30 saniye, 2 dakika veya daha uzun sürekli yük altında stabil kalıyor mu?
  • Bağlantı sayısı arttıkça verimlilik nerede plato yapıyor?

Ancak önemli ayrım şu: wrk bir fonksiyonel test aracı değildir. Hızı ölçer; JSON gövdesinin doğru olup olmadığını, durum kodunun beklenen değer olup olmadığını veya API sözleşmesinin bozulup bozulmadığını doğrulamaz.

Yük testi kavramlarını daha geniş bağlamda görmek isterseniz bu API yük testi rehberi wrk ile ölçtüğünüz metriklerin ne anlama geldiğini açıklar.

wrk Kurulumu

macOS

Homebrew ile kurulum en pratik yoldur:

brew install wrk
Enter fullscreen mode Exit fullscreen mode

Apple Silicon kullanıyorsanız Homebrew ikilisini tercih edin. Kaynaktan derleme sırasında LuaJIT ARM64 sorunlarıyla uğraşmanız gerekmez.

Kurulumu doğrulayın:

wrk --version
Enter fullscreen mode Exit fullscreen mode

Linux

Resmi bir apt paketi olmadığı için kaynaktan derleyin.

Önce bağımlılıkları kurun:

sudo apt-get update
sudo apt-get install build-essential libssl-dev git -y
Enter fullscreen mode Exit fullscreen mode

Ardından depoyu klonlayıp derleyin:

git clone https://github.com/wg/wrk.git
cd wrk
make
Enter fullscreen mode Exit fullscreen mode

Oluşan ikiliyi PATH içine taşıyın:

sudo cp wrk /usr/local/bin
Enter fullscreen mode Exit fullscreen mode

Kontrol edin:

wrk --version
Enter fullscreen mode Exit fullscreen mode

İlk wrk Testinizi Çalıştırın

Temel komut yapısı şöyledir:

wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html
Enter fullscreen mode Exit fullscreen mode

Bu komut şu anlama gelir:

  • -t12: 12 iş parçacığı kullan.
  • -c400: Toplam 400 açık HTTP bağlantısı tut.
  • -d30s: Testi 30 saniye çalıştır.
  • Son argüman: Test edilecek URL.

Daha pratik bir başlangıç komutu:

wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Bu komut 8 thread, 200 bağlantı ve 30 saniyelik test kullanır. --latency bayrağı, yüzdelik gecikme dağılımını da yazdırır.

Önemli Bayraklar

Sık kullanacağınız bayraklar:

Bayrak Açıklama
-t, --threads wrk'nin kullanacağı OS thread sayısı
-c, --connections Toplam açık bağlantı sayısı
-d, --duration Test süresi
--latency Gecikme yüzdeliklerini yazdırır
--timeout Belirtilen sürede yanıt gelmezse isteği timeout sayar
-H HTTP header ekler
-s Lua betiği çalıştırır

Örneğin timeout eklemek için:

wrk -t8 -c200 -d30s --latency --timeout 2s http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

--timeout kullanmak önemlidir. Aksi halde çok yavaş yanıtlar gecikme sayılarını şişirebilir ve testin davranışını yorumlamayı zorlaştırabilir.

Thread ve Bağlantı Sayısını Seçme

Başlangıç için pratik yaklaşım:

  1. Thread sayısını CPU çekirdeği sayısına yakın seçin.
  2. Bağlantı sayısını modellemek istediğiniz eşzamanlı kullanıcı sayısına göre ayarlayın.
  3. Bağlantı sayısını kademeli artırın.
  4. RPS artışı durduğunda veya p99 gecikme hızlı yükseldiğinde sınırı not edin.

Örnek:

wrk -t4 -c50 -d30s --latency http://localhost:3000/api/users
wrk -t4 -c100 -d30s --latency http://localhost:3000/api/users
wrk -t4 -c200 -d30s --latency http://localhost:3000/api/users
wrk -t4 -c400 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Sadece sunucuyu değil, yük üreten makineyi de izleyin. Eğer wrk çalıştıran makine CPU limitine takılırsa ölçtüğünüz sınır sunucunun değil, istemcinin sınırı olur.

Çıktıyı Okuma

Örnek wrk çıktısı:

Running 5s test @ http://10.135.232.163:3000
  2 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.82ms    2.64ms  26.68ms   85.81%
    Req/Sec   550.90    202.40     0.98k    68.00%
  5494 requests in 5.01s, 1.05MB read
Requests/sec:   1096.54
Transfer/sec:    215.24KB
Enter fullscreen mode Exit fullscreen mode

Önce en alttaki iki satıra bakın.

Requests/sec 

Requests/sec:   1096.54
Enter fullscreen mode Exit fullscreen mode

Bu, sunucunun ortalama saniyede kaç isteği tamamladığını gösterir. Kod değişiklikleri, deployment ayarları veya altyapı değişiklikleri arasında karşılaştıracağınız ana metriklerden biridir.

Transfer/sec 

Transfer/sec:    215.24KB
Enter fullscreen mode Exit fullscreen mode

Saniye başına aktarılan veri miktarıdır. Büyük payload'larda veya ağ bant genişliği sınırından şüpheleniyorsanız önemlidir.

Latency 

Latency     3.82ms    2.64ms  26.68ms   85.81%
Enter fullscreen mode Exit fullscreen mode

Bu satır şunları gösterir:

  • Ortalama gecikme: 3.82ms
  • Standart sapma: 2.64ms
  • Maksimum gecikme: 26.68ms
  • Örneklerin standart sapma içindeki oranı: %85.81

Ortalama tek başına yeterli değildir. Maksimum ve yüzdelikler, kuyruk gecikmesini anlamak için daha değerlidir.

p50, p90 ve p99 Gecikmeyi Yorumlama

--latency eklediğinizde wrk şu tarz bir blok üretir:

  Latency Distribution
     50%    3.21ms
     75%    4.86ms
     90%    7.09ms
     99%   14.13ms
Enter fullscreen mode Exit fullscreen mode

Bu değerleri şöyle okuyun:

  • 50%: İsteklerin yarısı bu süreden hızlı tamamlandı.
  • 90%: İsteklerin %90'ı bu süreden hızlı tamamlandı.
  • 99%: İsteklerin %99'u bu süreden hızlı tamamlandı.

Özellikle 99% değerini izleyin. Ortalama 3.82ms iken p99 14.13ms ise kullanıcıların küçük ama önemli bir kısmı ortalamanın çok üzerinde bekliyor demektir.

Performans analizinde çoğu zaman sorun ortalamada değil, kuyruktadır.

POST İstekleri Gönderme

Varsayılan olarak wrk GET isteği gönderir. POST, request body veya özel header kullanmak için Lua betiği yazabilirsiniz.

post.lua oluşturun:

wrk.method = "POST"
wrk.body   = '{"name": "Ada", "role": "engineer"}'
wrk.headers["Content-Type"] = "application/json"
Enter fullscreen mode Exit fullscreen mode

Çalıştırın:

wrk -t4 -c100 -d30s -s post.lua --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Bu komut:

  • POST /api/users çağırır.
  • JSON gövdesi gönderir.
  • Content-Type: application/json header'ı ekler.
  • 100 bağlantıyla 30 saniyelik yük uygular.

Form Data ile POST Gönderme

Form encoded body göndermek için:

wrk.method = "POST"
wrk.body   = "foo=bar&baz=quux"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"
Enter fullscreen mode Exit fullscreen mode

Çalıştırma komutu aynıdır:

wrk -t4 -c100 -d30s -s post.lua --latency http://localhost:3000/api/form
Enter fullscreen mode Exit fullscreen mode

Header Ekleme

Sadece header eklemeniz gerekiyorsa Lua betiği şart değildir. -H kullanabilirsiniz:

wrk -t4 -c100 -d30s \
  -H "Authorization: Bearer TOKEN123" \
  --latency \
  http://localhost:3000/api/protected
Enter fullscreen mode Exit fullscreen mode

Birden fazla header için:

wrk -t4 -c100 -d30s \
  -H "Authorization: Bearer TOKEN123" \
  -H "X-Client-Version: dev" \
  --latency \
  http://localhost:3000/api/protected
Enter fullscreen mode Exit fullscreen mode

Kural basit:

  • Sadece header gerekiyorsa -H kullanın.
  • Body, farklı HTTP metodu veya request başına dinamik mantık gerekiyorsa Lua betiği kullanın.

Basit Test Planı: Kademeli Yük Artırma

Tek bir komutla sonuca varmak yerine, yükü kademeli artırın.

Örnek plan:

wrk -t4 -c50  -d30s --latency http://localhost:3000/api/users
wrk -t4 -c100 -d30s --latency http://localhost:3000/api/users
wrk -t4 -c200 -d30s --latency http://localhost:3000/api/users
wrk -t4 -c400 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Her çalıştırmada şunları kaydedin:

  • Requests/sec
  • p50
  • p90
  • p99
  • timeout veya bağlantı hataları
  • sunucu CPU/RAM kullanımı
  • veritabanı bağlantı havuzu kullanımı
  • uygulama log'larında hata oranı

Amaç sadece en yüksek RPS değerini bulmak değildir. Amaç, kabul edilebilir p99 gecikmeyle sürdürülebilir kapasiteyi bulmaktır.

Süreyi Nasıl Seçmelisiniz?

Hızlı smoke test için birkaç saniye yeterli olabilir:

wrk -t2 -c20 -d5s --latency http://localhost:3000/health
Enter fullscreen mode Exit fullscreen mode

Daha güvenilir ölçüm için en az 30 saniye kullanın:

wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Sızıntılar, cache davranışı, connection pool tükenmesi veya uzun süreli bozulmaları görmek için birkaç dakikaya çıkın:

wrk -t8 -c200 -d5m --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

HTTPS Endpoint Test Etme

wrk HTTPS URL'lerini test edebilir:

wrk -t8 -c200 -d30s --latency https://api.example.com/users
Enter fullscreen mode Exit fullscreen mode

TLS el sıkışması ve şifreleme CPU maliyeti ekler. Bu nedenle HTTPS altında ham RPS değerinin HTTP'ye göre daha düşük olması normaldir.

Linux'ta derleme sırasında libssl-dev gereksiniminin nedeni de budur.

Sınırlamalar: wrk Doğruluğu Kontrol Etmez

wrk yalnızca HTTP alışverişinin tamamlandığını ve ne kadar sürdüğünü ölçer. Şunları doğrulamaz:

  • Durum kodu gerçekten 200 mü?
  • Yanıt gövdesi beklenen JSON şemasına uyuyor mu?
  • İş mantığı doğru çalışıyor mu?
  • API sözleşmesi bozuldu mu?
  • Yanıt hatalı ama hızlı mı dönüyor?

Örneğin endpoint her istekte 500 dönüyorsa wrk yine yüksek Requests/sec raporlayabilir. Çünkü hatalı yanıt da tamamlanmış bir HTTP yanıtıdır.

Bu yüzden wrk şu soruya yanıt verir:

Yük altında yeterince hızlı mı?

Ama şu soruya yanıt vermez:

Doğru çalışıyor mu?

Bu iki soruyu ayrı araçlarla çözmek gerekir. Bu nedenle ekipler genellikle performans ölçümünü bir fonksiyonel test paketiyle birlikte kullanır.

Apidog ve Fonksiyonel Test Katmanı

Sağlıklı iş akışı iki aşamalıdır.

1. Önce davranışı doğrulayın

Performans ölçmeden önce endpoint'in doğru çalıştığını kanıtlayın.

Apidog ile gerçek istekler gönderen test senaryoları oluşturabilirsiniz. Bu senaryolarda şunları doğrulayabilirsiniz:

  • HTTP durum kodları
  • JSON alanları
  • Yanıt şeması
  • İş mantığı beklentileri
  • Ortam değişkenleri
  • Zincirlenmiş istekler arası veri aktarımı

Bu katman, wrk'nin hızlı gibi gösterebileceği bozuk endpoint'leri yakalar.

2. Sonra verimliliği ölçün

Davranış doğrulandıktan sonra aynı endpoint'lere wrk ile yük uygulayın:

wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Böylece performans sayılarınız anlamlı hale gelir. Çünkü ölçtüğünüz endpoint'in gerçekten doğru çalıştığını önceden doğrulamış olursunuz.

Apidog ayrıca fonksiyonel ve yük çalışmalarını tek yerde tutmak isteyen ekipler için yerleşik performans testi özelliği de sunar. wrk ise ham komut satırı performans ölçümü için iyi bir özel araçtır.

CI'da Apidog CLI ile Doğruluk Kapısı Eklemek

Fonksiyonel testleri yalnızca lokal makinede çalıştırmak yeterli değildir. CI pipeline içinde de çalıştırabilirsiniz.

Apidog CLI'ı kurun:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Kaydedilmiş bir senaryoyu veya test paketini çalıştırın:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <senaryoVeyaPaketId> \
  -e <ortamId> \
  -r cli,html,junit
Enter fullscreen mode Exit fullscreen mode

Parametreler:

  • -t: Çalıştırılacak senaryo, klasör veya paket kimliği.
  • -e: Ortam kimliği.
  • -r: Rapor formatları. cli, html, json, junit kullanılabilir.

JUnit çıktısı çoğu CI sisteminde doğrudan test raporu olarak kullanılabilir.

Veri odaklı çalıştırmalar için:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <senaryoVeyaPaketId> \
  -e <ortamId> \
  -d ./test-data.csv \
  -r cli,junit
Enter fullscreen mode Exit fullscreen mode

-d veya --iteration-data, aynı senaryoyu farklı giriş verileriyle tekrar çalıştırmak için kullanılır.

Apidog CLI başsızdır. Etkileşimli istek gönderici veya yük üretici değildir. Pipeline içinde doğruluk kapısı olarak konumlandırın; performans ölçümü gerektiğinde wrk çalıştırın.

CI yapılandırması için şu kılavuzlara bakabilirsiniz:

Sıkça Sorulan Sorular

wrk ile ab (ApacheBench) arasındaki fark nedir?

İkisi de HTTP yükü gönderir ve saniyedeki istek sayısını raporlar. wrk çok iş parçacıklıdır ve olay döngüsü kullanır. Bu nedenle tek bir makineden daha yüksek yük üretebilir ve yüksek eşzamanlılığı daha iyi yönetir.

ab tek iş parçacıklıdır. Basit kontroller için kullanılabilir, ancak ağır yük üretiminde wrk genellikle daha iyi ölçeklenir.

İkisi de yanıt doğruluğunu kontrol etmez.

Kaç thread ve bağlantı kullanmalıyım?

CPU çekirdeği başına yaklaşık bir thread ile başlayın. Bağlantı sayısını simüle etmek istediğiniz eşzamanlılık düzeyine göre ayarlayın.

Örneğin 8 çekirdeğiniz ve 200 eşzamanlı istemci hedefiniz varsa:

wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Sonra bağlantı sayısını artırarak RPS ve p99 davranışını izleyin.

wrk HTTPS endpoint'leri test edebilir mi?

Evet. URL'yi https:// ile verin:

wrk -t8 -c200 -d30s --latency https://api.example.com/users
Enter fullscreen mode Exit fullscreen mode

TLS CPU maliyeti eklediği için HTTPS testlerinde RPS değeri HTTP'ye göre daha düşük olabilir.

wrk durum kodunu veya response body'yi doğrular mı?

Hayır. wrk tamamlanmış HTTP alışverişlerini sayar ve zamanlamayı ölçer. Durum kodu, JSON şeması veya response body doğrulaması yapmaz.

Bu nedenle önce Apidog CLI gibi bir fonksiyonel test katmanıyla doğruluğu test edin, ardından wrk ile verimliliği ölçün.

Bir yük testi ne kadar sürmeli?

Hızlı kontrol için 5-10 saniye yeterli olabilir. Daha güvenilir ölçüm için 30 saniye veya birkaç dakika kullanın.

Başlangıç varsayılanı olarak:

wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

Sadece uzun süreli yük altında ortaya çıkan sorunları arıyorsanız süreyi artırın:

wrk -t8 -c200 -d5m --latency http://localhost:3000/api/users
Enter fullscreen mode Exit fullscreen mode

wrk sonucunda hangi metriğe bakmalıyım?

Öncelik sırası genellikle şöyledir:

  1. Requests/sec
  2. p99 gecikme
  3. p90 gecikme
  4. timeout veya bağlantı hataları
  5. sunucu CPU/RAM/veritabanı metrikleri

Yüksek RPS tek başına iyi sonuç değildir. Kabul edilebilir p99 gecikme ile sürdürülebilir RPS hedefleyin.

Top comments (0)