Bir uç nokta yayınladınız. Tarayıcınızda çalışıyor. Ama 400 kişi aynı anda vurduğunda ne olduğunu bilmiyorsunuz. Gecikme sabit mi kalıyor, yoksa doksan dokuzuncu yüzdelik dilim patlıyor mu? Kutu saniyede 1.000 isteği kaldırabilir mi, yoksa 300'de mi çöker?
wrk bunu cevaplar. Belirli bir URL'ye çok sayıda HTTP trafiği gönderen ve sunucunun bu yük altında ne kadar hızlı yanıt verdiğini bildiren küçük bir komut satırı aracıdır.
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 oluşturur ve sunucunun döndürdüğü gecikmeyi ve istek oranını ölçer. Çoklu iş parçacığı ve ölçeklenebilir bir olay döngüsü (Linux'ta epoll, macOS'ta kqueue) kullanır, böylece tek bir örnek, bir dizi yük kutusu ihtiyacı olmadan çok fazla trafik üretebilir.
Ham performans sayıları istediğinizde wrk'ye başvurun:
- Bu uç nokta saniyede kaç isteği sürdürebilir?
- Medyan ile kuyrukta gecikme nasıl görünür?
- Sunucu sürekli bir pencerede dayanır mı, yoksa bir dakika sonra bozulur mu?
wrk bir performans ölçüm aracıdır, bir test paketi değildir. Hızı ölçer. JSON gövdesinin doğru olup olmadığını, durum kodunun 200 olup olmadığını veya API sözleşmesinin tutarlı olup olmadığını kontrol etmez. Bu ayrımı aklınızda bulundurun. Bunu sona doğru tekrar ele alacağız, çünkü wrk'yi gerçek bir test iş akışına nasıl dahil ettiğinizi değiştiriyor. Daha geniş resmi önce görmek isterseniz, bu API yük testi rehberi wrk'nin pratikte uyguladığı kavramları ele alır.
wrk Kurulumu
macOS
Homebrew'de önceden derlenmiş bir ikili vardır, bu en kolay yoldur:
brew install wrk
Apple Silicon'da bu önemlidir. Kaynaktan derlemek LuaJIT ARM64 sorunlarına neden olabilir, bu yüzden Homebrew ikilisi sizi baş ağrısından kurtarır.
Linux (kaynaktan derleme)
Resmi bir apt paketi yoktur, bu yüzden kendiniz derlemeniz gerekir. Önce araç zincirini ve OpenSSL başlıklarını kurun:
sudo apt-get install build-essential libssl-dev git -y
Ardından klonlayın ve derleyin:
git clone https://github.com/wg/wrk.git
cd wrk
make
Bu, geçerli dizinde bir wrk ikilisi oluşturur. Her yerden çağırabilmek için PATH'inize taşıyın:
sudo cp wrk /usr/local/bin
Çalıştığını doğrulayın:
wrk --version
Temel Komut
Her wrk çalıştırmasının şekli şöyledir:
wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html
Dört şey oluyor. Bayrakları inceleyelim.
-t, --threadswrk'nin başlattığı OS iş parçacığı sayısını ayarlar. İyi bir başlangıç noktası, CPU çekirdeği başına bir iş parçacığıdır. Burada 12.-c, --connectionstüm iş parçacıklarında açık tutulan toplam HTTP bağlantı sayısını ayarlar. Burada 400 bağlantı 12 iş parçacığına yayılmıştır. Bağlantılar, eşzamanlı istemcileri nasıl simüle ettiğinizdir.-d, --durationtestin ne kadar süreceğini ayarlar.30s,2mveya2hgibi değerleri kabul eder. Burada 30 saniyedir.
Sürekli kullanacağınız iki bayrak daha:
--latencyayrıntılı bir gecikme yüzdelik dilimi dökümü yazdırır. Bunu hemen hemen her zaman açın. Ortalamalar kuyruk gecikmesini gizler ve kuyruk genellikle kullanıcılara zarar veren şeydir.--timeout, örneğin--timeout 2sgibi, belirttiğiniz süre içinde yanıt gelmezse isteği zaman aşımına uğramış olarak kaydeder. Onsuz, yavaş yanıtlar gecikme sayılarınızı çarpıtabilir.
Sıkça başvuracağınız bir çalıştırma şöyle görünür:
wrk -t8 -c200 -d30s --latency http://localhost:3000/api/users
Sekiz iş parçacığı, 200 bağlantı, 30 saniye, sonunda tam gecikme dağılımı yazdırılır.
Çıktıyı Okuma
wrk kısa bir rapor yazdırır. İşte küçük bir hizmete karşı gerçek bir çalıştırma:
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
En alttan yukarıya doğru okuyun, çünkü son iki satır manşet niteliğindedir.
Requests/sec (İstekler/saniye) verimliliktir: sunucunun ortalama olarak saniyede tamamladığı istek sayısı. Burada 1.096'dır. Bu, çalıştırmalar ve kod değişiklikleri arasında karşılaştırdığınız sayıdır.
Transfer/sec (Aktarım/saniye) bant genişliğidir: saniyede ne kadar veri aktarıldığı. Yükler büyük olduğunda veya CPU sınırlı olmak yerine bant genişliği sınırlı olduğunuzdan şüpheleniyorsanız faydalıdır.
Şimdi Thread Stats (İş Parçacığı İstatistikleri) tablosu, sadece ortalamayı değil, dağılımı da açıklar:
- Latency (Gecikme) satırı: ortalama gecikme 3.82ms idi, ancak standart sapma 2.64ms idi ve maksimum 26.68ms'ye yükseldi. Ortalamaya göre yüksek bir maksimum sinyaldir. Çoğu istek hızlı olsa bile bazı istekler yavaştır.
- Req/Sec (İstek/saniye) satırı: iş parçacığı başına istek oranı, yine kendi yayılımıyla.
+/- Stdev sütunu, örneklerin yüzde kaçının bir standart sapma içinde olduğunu gösterir. Daha düşük yüzdeler, daha geniş, daha az tahmin edilebilir bir yayılım anlamına gelir.
5494 requests in 5.01s satırı, çalıştırmanın fiilen gönderdiği toplam hacmi doğrular.
--latency eklediğinizde, wrk bir yüzdelik dilim bloğu yazdırır, böylece kuyruğu doğrudan görebilirsiniz:
Latency Distribution (Gecikme Dağılımı)
50% 3.21ms
75% 4.86ms
90% 7.09ms
99% 14.13ms
İzlenecek sayı 99. yüzdelik dilimdir. İsteklerin %99'u 14ms'de tamamlanıyorsa ancak ortalamanız 3.82ms ise, yüz kullanıcıdan biri ortalamanın önerdiğinden çok daha uzun süre beklemektedir. Ortalamalar kuyruklar hakkında yalan söyler. Yüzdelikler söylemez.
Lua Betiğiyle POST İstekleri ve Özel Başlıklar Gönderme
Varsayılan olarak wrk GET istekleri gönderir. Bir POST göndermek, bir gövde eklemek veya özel başlıklar ayarlamak için -s ile bir Lua betiği geçirirsiniz.
post.lua adlı bir dosya oluşturun:
wrk.method = "POST"
wrk.body = '{"name": "Ada", "role": "engineer"}'
wrk.headers["Content-Type"] = "application/json"
Üç alan işi yapar. wrk.method HTTP fiilini ayarlar. wrk.body istek gövdesini ayarlar. wrk.headers, her anahtarın bir başlık adı olduğu bir tablodur.
Betiği -s ile işaret ederek çalıştırın:
wrk -t4 -c100 -d30s -s post.lua --latency http://localhost:3000/api/users
JSON yerine form kodlu bir POST için, wrk deposu bu tam örneği içerir:
wrk.method = "POST"
wrk.body = "foo=bar&baz=quux"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"
Daha basit durumlar için, bir betiğe gerek kalmadan -H bayrağıyla başlıkları da ayarlayabilirsiniz:
wrk -t4 -c100 -d30s -H "Authorization: Bearer TOKEN123" --latency http://localhost:3000/api/protected
Bir veya iki başlık için -H kullanın. Bir gövdeye, GET olmayan bir yönteme veya istek başına mantığa ihtiyacınız olduğunda bir Lua betiği kullanın.
Sınırlamalar: wrk Doğruluğu Kontrol Etmez
İnsanların gözden kaçırdığı kısım burası. wrk sunucunun ne kadar hızlı yanıt verdiğini söyler. Ancak yanıtın doğru olup olmadığını söylemez.
wrk'yi her istekte HTTP 500 döndüren bir uç noktaya yönlendirin, yüksek bir saniyede istek sayısı ile temiz görünümlü bir rapor alırsınız. wrk tamamlanmış bir HTTP alışverişini sayar. Durum kodunu doğrulamaz, yanıt gövdesini bir şemaya göre doğrulamaz veya API'nin yapması gerekeni yaptığını doğrulamaz. Hatalar bile hızlı görünebilir, çünkü istekleri erken reddeden bir sunucu istek başına daha az iş yapar.
Bu yüzden wrk "yük altında yeterince hızlı mı?" sorusunu yanıtlar. "Doğru mu?" sorusunu yanıtlayamaz. Her iki soru da önemlidir ve farklı araçlar gerektirir. Bozuk bir uç noktanın yük numarası, güvenmemeniz gereken bir sayıdır. Ekiplerin bir performans ölçüm aracını bir fonksiyonel test paketiyle eşleştirmesinin nedeni tam olarak budur. Biri hızı kanıtlar. Diğeri davranışı kanıtlar.
Apidog ve Fonksiyonel Testin Yeri
Temiz iş akışı, sırayla çalıştırılan iki katmandır.
İlk olarak, davranışı doğrulayın. Bir uç noktanın ne kadar hızlı olduğunu önemsemeden önce, doğru olduğunu onaylayın. Apidog'da gerçek istekler gönderen ve geri dönenleri (durum kodları, JSON alanları, yanıt şeması ve iş mantığı) doğrulayan test senaryoları oluşturursunuz. İstekleri zincirleyebilir, adımlar arasında veri aktarabilir ve aynı senaryoyu farklı ortamlarda çalıştırabilirsiniz. Bu, wrk'nin mutlu bir şekilde performansını ölçtüğü bozuk 500'ü yakalayan katmandır.
Ardından, verimliliği ölçün. Davranış doğrulandıktan sonra, eşzamanlılık ve sürekli yük altında nasıl dayandıklarını görmek için aynı uç noktalara karşı wrk'yi çalıştırın. Apidog ayrıca fonksiyonel ve yük çalışmalarını tek bir yerde tutmak isterseniz yerleşik performans testi özelliğine de sahiptir, ancak wrk ham komut satırı performans ölçümü için mükemmel bir özel araçtır.
Fonksiyonel katman sadece dizüstü bilgisayarınızda değil, CI'da da çalışır. Apidog CLI başsızdır, bu nedenle Node çalıştırabilen herhangi bir ardışık düzen adımına düşer. Kurun:
npm install -g apidog-cli
Ardından kimliğe göre kaydedilmiş bir test senaryosunu veya paketini çalıştırın:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <senaryoVeyaPaketId> \
-e <ortamId> \
-r cli,html,junit
-t çalıştırılacak senaryo, klasör veya paket kimliğidir. -e ortam kimliğidir. -r rapor formatlarını seçer: cli, html, json ve junit bir veya daha fazlası. JUnit çıktısı, geçme/kalma denetimi için çoğu CI sistemine doğrudan takılır. Veri odaklı çalıştırmalar için, aynı senaryoyu birçok giriş satırı üzerinde yinelemek için -d (veya --iteration-data) ve bir dosya yolu veya test veri kimliği ekleyin.
CLI, kaydedilmiş Apidog senaryolarını ve paketlerini çalıştırır. Başsızdır, etkileşimli bir istek gönderici değildir ve bir yük oluşturucu değildir. Bu, doğruluk kapısıdır. wrk hız göstergesidir. Ardışık düzeninizde doğruluk kapısını çalıştırın (kopyala-yapıştır yapılandırması için bu CLI CI/CD kılavuzuna veya GitHub Actions kılavuzuna bakın), ardından verimlilik sayılarına ihtiyacınız olduğunda wrk ile performans testi yapın. Tam CLI referansı diğer bayrakları kapsar.
Sıkça Sorulan Sorular
wrk ile ab (ApacheBench) arasındaki fark nedir? Her ikisi de HTTP yükü gönderir ve saniyedeki istekleri raporlar. wrk çok iş parçacıklıdır ve bir olay döngüsü kullanır, bu nedenle tek bir makineden daha fazla yük üretir ve yüksek eşzamanlılığı daha iyi yönetir. ab tek iş parçacıklıdır. Tek bir kutudan ağır yük için wrk genellikle daha fazla ölçeklenir. İkisi de yanıt doğruluğunu kontrol etmez.
Kaç iş parçacığı ve bağlantı kullanmalıyım? CPU çekirdeği başına bir iş parçacığıyla başlayın ve bağlantıları simüle etmek istediğiniz eşzamanlılık düzeyine ayarlayın. 8 çekirdeğiniz varsa ve 200 eşzamanlı istemci modellemek istiyorsanız, -t8 -c200 deneyin. İstemci makinesini izleyin. wrk'nin kendisi CPU sınırlıysa, sayılarınız sunucunun değil, yük oluşturucunun sınırını yansıtır. Verimlilik artışı durana kadar bağlantıları artırın.
wrk HTTPS uç noktalarını test edebilir mi? Evet. Bir https:// URL'sine yönlendirin ve wrk TLS'yi yönetir. Linux derlemesinin libssl-dev'e ihtiyaç duymasının nedeni budur. TLS el sıkışmaları her iki uçta da CPU maliyeti ekler, bu nedenle düz HTTP'ye göre HTTPS'ye karşı daha düşük ham verimlilik bekleyin.
wrk yanıt gövdesini veya durum kodunu doğrular mı? Hayır. wrk tamamlanmış HTTP alışverişlerini sayar ve zamanlamayı ölçer. Durum kodları veya gövdeleri üzerinde doğrulama yapmaz, bu nedenle hatalar döndüren bir uç nokta hala yüksek saniyede istek sayısı gösterebilir. Doğruluğu doğrulamak için Apidog CLI aracılığıyla çalıştırılan bir fonksiyonel test paketi kullanın, ardından verimlilik için wrk kullanın.
Bir yük testi ne kadar sürmelidir? Soğuk önbellekler ve JIT derlemesi gibi ısınma etkilerini aşacak kadar uzun. Hızlı bir kontrol için birkaç saniye yeterlidir, ancak 30 saniyeden birkaç dakikaya kadar daha kararlı sayılar verir ve yalnızca sürekli yük altında ortaya çıkan bozulmaları yüzeye çıkarır. Mantıklı bir varsayılan olarak -d30s kullanın ve yavaş sızıntıların peşindeyken süreyi uzatın.