Makale içeriği

Proxy üzerinden çalışmak neredeyse her zaman tek bir soruya takılır: gecikmeler artmadan ve hatalar başlamadan önce "sizin istemciniz - proxy - hedef sunucu" zinciri kaç paralel isteği gerçekten kaldırabilir? Bu rehber size bunu önceden nasıl ölçeceğinizi öğretir; yani saatlerce süren kesintilerin yaşandığı büyük bir veri çekme işlemi sırasında değil, daha önce.

Giriş: Sınırı Büyük Bir Veri Çekme Sırasında Değil, Neden Önceden Bilmek Gerekir?

Tipik bir durumu düşünün. Bir proxy havuzu üzerinden büyük bir genel veri toplama görevi başlatıyorsunuz. İlk birkaç bin istekte her şey yolunda gider, ancak sonra gecikmeler artar, bazı istekler zaman aşımına uğrayarak düşmeye başlar ve suçun kodunuzda mı, proxylerde mi yoksa hedef sunucuda mı olduğunu anlayamazsınız. Bu noktada hem zaman hem de muhtemelen veri kaybetmişsinizdir.

Bunun yerine, önceden kontrollü bir yük testi yapıp bozulma noktasını bulmak çok daha mantıklıdır. Böylece güvenli iş parçacığı sayısını seçebilir ve veri çekme süresini doğru planlayabilirsiniz.

Okuyucu Sonunda Ne Kazanacak?

Bu rehberi tamamladıktan sonra şunları kendiniz yapabileceksiniz:

  • k6 içinde doğru bir yük testi senaryosu oluşturup proxy üzerinden çalıştırmak.
  • Aynı senaryoyu JMeter içinde test planına proxy ayarı ekleyerek tekrarlamak.
  • Raporu okumak: RPS (saniyedeki istek), yüzdelik dilimlerdeki gecikmeler ve hata oranını anlamak.
  • Proxy sınırını, kendi istemcinizin sınırından ve hedef sunucunun limitinden ayırt etmek.
  • Sonuçları iş parçacığı sayısına, havuz boyutuna ve beklenen veri çekme süresine dönüştürmek.

Bu Rehber Kimin İçin?

Bu materyal orta seviye mühendisler, veri analistleri ve geliştiriciler için tasarlanmıştır. JavaScript'te basit scriptler yazdıysanız veya komut satırından programlar çalıştırdıysanız, bu rehber size uygun olacaktır. Yeni başlayanlar için her terimi basit kelimelerle açıklıyoruz.

Önceden Bilmeniz Gerekenler

Temel beceriler yeterlidir: terminali nasıl açacağınızı, bir programı nasıl kuracağınızı ve bir metin dosyasını nasıl düzenleyeceğinizi bilmeniz yeterli. HTTP'yi "istek ve yanıt nedir" düzeyinde bilmek artı olacaktır, ancak zorunlu değildir.

Ne Kadar Zaman Gerekir?

Araçların kurulumu yaklaşık 30-40 dakika sürer. İlk çalışan k6 testinizi bir saat içinde başlatırsınız. JMeter ve analizle birlikte tam döngü, sakin bir çalışmayla 3-4 saat sürer.

⚠️ Dikkat: Rehberdeki tüm örnekler, kendi test ortamınızı veya yük oluşturmak için açık izniniz olan kaynakları test etmek içindir. İzin almadan başkalarının hizmetlerine yük testi yapmak kabul edilemez. Etik konularına son bölümde ayrıca değineceğiz.

Ön Hazırlık: Araçlar, Gereksinimler ve Erişimler

Ölçmeye başlamadan önce çalışma ortamını kurmamız gerekiyor. Burada gerekli her şeyi listeleyip her bileşenin nasıl kurulacağını göstereceğiz.

Gerekli Araçlar ve Erişimler

  • k6 - Senaryoları JavaScript ile yazılan hafif bir yük testi aracı.
  • Apache JMeter - Java tabanlı, grafik arayüze sahip klasik bir araç.
  • Java 17 veya daha yenisi - JMeter'ın çalışması için gereklidir.
  • Proxeon'dan proxy erişimi: adres, port, kullanıcı adı ve şifre. Bu bilgileri hizmetin kişisel panelinizden alırsınız.
  • Test hedefi - Kendi test ortamınız veya üzerinde anlaşılmış bir kaynak.

Sistem Gereksinimleri

Rahat çalışmak için 4 çekirdekli işlemci ve 8 GB RAM'e sahip bir makine yeterlidir. Yüksek yükler için (binlerce sanal kullanıcı) 8 çekirdek ve 16 GB RAM önerilir. İşletim sistemi Windows, macOS veya Linux olabilir; tüm araçlar platformlar arasıdır.

İpucu: Yük üretecini ayrı bir makinede veya ayrı bir bulut sunucusunda çalıştırın. Böylece dizüstü bilgisayarınıza gelen yükü proxy yüküyle karıştırmazsınız.

k6 Kurulumu

  1. Sisteminiz için resmi kurulum yöntemini açın: macOS'ta Homebrew paket yöneticisi ile brew install k6 komutunu kullanın.
  2. Windows'ta Chocolatey paket yöneticisini kullanın: choco install k6.
  3. Linux'ta projenin deposundan paketi indirin ve sistem paket yöneticinizle kurun.
  4. Kurulumu k6 version komutuyla doğrulayın - yanıt olarak sürüm numarasını göreceksiniz.

✅ Kontrol: k6 version komutu bir sürüm satırı gösteriyor ve "komut bulunamadı" hatası vermiyorsa, araç doğru kurulmuştur.

Java ve JMeter Kurulumu

  1. OpenJDK 17 veya daha yeni bir sürümü kurun ve java -version komutuyla doğrulayın.
  2. Apache JMeter arşivini projenin resmi web sitesinin indirme bölümünden indirin.
  3. Arşivi uygun bir klasöre, örneğin ana dizininize açın.
  4. Açılan JMeter klasörünün içindeki bin alt klasörüne gidin.
  5. jmeter (Linux ve macOS'ta) veya jmeter.bat (Windows'ta) dosyasını çalıştırın.
  6. Solda test planı ağacı olan grafik pencerenin açılmasını bekleyin.

✅ Kontrol: Soldaki ağaçta "Test Plan" öğesiyle birlikte JMeter penceresi açıldıysa, her şey hazır demektir.

Yedekler ve Test Ortamı Hazırlığı

Kendi hizmetinizi test ediyorsanız, önceden ortamın bir anlık görüntüsünü veya yedeğini alın. Yük, prodüksiyona zarar vermemelidir. Mümkünse canlı sunucu yerine ortamın bir kopyasını kullanın.

Temel Kavramlar Basit Dille

Raporları okumak ve terimler arasında kaybolmamak için anahtar kavramları inceleyelim.

Bant Genişliği ve RPS

Bant genişliği, sistemin birim zamanda yaptığı faydalı iş miktarıdır. HTTP bağlamında genellikle RPS - saniyedeki istek sayısı - ile ölçülür. Kabul edilebilir gecikmelerde RPS ne kadar yüksekse o kadar iyidir.

Gecikme ve Yüzdelik Dilimler

Gecikme (gecikme süresi), isteğin gönderilmesinden yanıtın alınmasına kadar geçen süredir. Tek bir ortalama değer yanıltıcıdır çünkü nadir görülen yavaş istekler içinde kaybolur. Bu nedenle yüzdelik dilimler kullanılır.

p95 yüzdelik dilimi şu anlama gelir: isteklerin yüzde 95'i bu değerden daha hızlı, yüzde 5'i ise daha yavaştı. p99 yüzdelik dilimi en yavaş isteklerin davranışını gösterir. Gerçek kullanıcı deneyimini en iyi yansıtanlar p95 ve p99'dur.

Hata Oranı ve Bozulma Noktası

Hata oranı, zaman aşımları, bağlantı reddi, 5xx yanıt kodları gibi başarısız tamamlanan isteklerin yüzdesidir. Bozulma noktası, yük artışının RPS'yi artırmayı bıraktığı, ancak gecikmelerin ve hataların keskin bir şekilde arttığı noktadır. Aradığımız sınır işte budur.

Paralellik ve Sanal Kullanıcılar

Paralellik, aynı anda kaç isteğin yürütüldüğüdür. k6'da VU (sanal kullanıcılar) ile, JMeter'da ise grup içindeki iş parçacığı sayısı (Thread Group) ile tanımlanır. Bir VU veya iş parçacığı istekleri sırayla gönderir; çok sayıda olanlar paralel yük oluşturur.

Yük Zincirinde Proxy

Proxy, isteklerinizin üzerinden geçtiği ara bir düğümdür. Kendi eşzamanlı bağlantı ve bant genişliği sınırına sahiptir. Amacımız, bu düğümün hangi paralellik seviyesinde darboğaz haline geldiğini anlamaktır.

İpucu: Little yasasını aklınızda tutun: ortalama eşzamanlı istek sayısı yaklaşık olarak RPS çarpı ortalama gecikme süresine (saniye cinsinden) eşittir. Bu, gereken paralelliği hızlıca tahmin etmenize yardımcı olur.

Adım 1: Test Hedefini ve Proxy Bilgilerini Hazırlayın

Bu aşamanın amacı: çalışan bir hedef adresi ve proxy'ye doğru biçimde bağlantı dizesi elde etmek.

  1. Yükleyeceğiniz hedefin URL'sini belirleyin. Kendi test ortamınız olsun, örneğin https://stend.local/api/health gibi bir adres.
  2. Hedefin normal bir tarayıcı veya curl aracıyla tek bir istekte hızlı ve istikrarlı yanıt verdiğinden emin olun.
  3. Proxeon proxy bilgilerinizi kişisel panelinizden alın: ana bilgisayar, port, kullanıcı adı ve şifre.
  4. http://KULLANICI:ŞİFRE@HOST:PORT biçiminde bağlantı dizesini oluşturun. Örneğin: http://user:pass@proxy.proxeon.net:8000.
  5. Proxy'yi örnekteki bilgileri kendi bilgilerinizle değiştirerek tek bir curl isteğiyle test edin.

Test isteği örneği:

curl -x http://user:pass@proxy.proxeon.net:8000 -H "Accept: application/json" https://stend.local/api/health

⚠️ Dikkat: Proxy kullanıcı adını ve şifresini asla depoya girecek kodun içinde saklamayın. Ortam değişkenlerini kullanın. Bunu sonraki adımlarda göstereceğiz.

Beklenen sonuç: curl, proxy üzerinden hedefinizden hatasız, doğru bir yanıt döndürür.

Olası sorunlar: curl asılı kalırsa - portu ve güvenlik duvarını kontrol edin. 407 yetkilendirme hatası dönerse - kullanıcı adını ve şifreyi tekrar kontrol edin.

✅ Kontrol: Hedeften gelen yanıt gövdesini, tam da proxy üzerinden aldığınızı görüyorsunuz. Yani zincir çalışıyor.

Adım 2: Doğru Yük Metodolojisini Anlayın

Bu aşamanın amacı: tek seferlik bir yük saldırısının neden yanıltıcı olduğunu ve doğru yük profilinin nasıl oluşturulacağını öğrenmek.

Tek Seferlik Yük Saldırısı Neden Yanıltıcıdır?

Aynı anda bin istek başlatırsanız, güzel ama anlamsız bir sayı elde edersiniz. Böyle bir saldırı, istikrarlı davranışı göstermez. Sistem, tamponlar sayesinde ani yük artışını yutabilir ve ardından bozulabilir. Veya soğuk bağlantılar nedeniyle başlangıçta boğulabilir.

Doğru Testin Üç Aşaması

Doğru bir yük testi üç aşamadan oluşur:

  1. Isınma (warm-up). İlk 30-60 saniyede yükü kademeli olarak artırıyoruz. Bağlantı havuzları, DNS önbellekleri ve iç yapılar ısınır. Isınma verilerini nihai istatistiklere dahil etmiyoruz.
  2. Kademeli Artış (ramp-up steps). Paralelliği kademeli olarak artırıyoruz: örneğin 10, 25, 50, 100, 200 VU, her kademede 1-2 dakika bekleyerek. Böylece bozulmanın hangi kademede başladığını görürüz.
  3. Sabit Yük (steady state). Yükü sınırın hemen altındaki bir seviyede sabitleyip 5-10 dakika tutuyoruz. Sabit yük, sistemin sürekli yük altında istikrarlı olup olmadığını, sızıntı ve kuyruk birikimi olup olmadığını gösterir.

İpucu: Testin ilk 30 saniyesinden asla sonuç çıkarmayın. Sistemin oturmuş moda girmesini bekleyin, ancak o zaman rakamlara bakın.

Her Kademede Ne Kaydediyoruz?

  • Elde edilen RPS.
  • p50, p95, p99 gecikmeleri.
  • Hata oranı.
  • Aktif VU veya iş parçacığı sayısı.

Bozulma noktasını şu şekilde belirleriz: RPS'nin artmayı bıraktığı, p95 ve hata oranının hızla artmaya başladığı kademeyi buluruz. Bir önceki kademe sizin güvenli çalışma noktanızdır.

✅ Kontrol: Isınmanın sabit yükten ne farkı olduğunu ve kademeli artışın neden gerekli olduğunu kendi kelimelerinizle açıklayabilirsiniz.

Adım 3: k6 - Proxy ve Yük Kademeleriyle Hazır Script

Bu aşamanın amacı: proxy üzerinden ısınma, kademeler ve sabit yükü geçen çalışan bir k6 senaryosu oluşturmak ve çalıştırmak.

k6 Proxy ile Nasıl Çalışır?

k6, proxy adresini HTTP_PROXY ve HTTPS_PROXY ortam değişkenlerinden okur. Bu kullanışlıdır: script'e veri yazmanıza gerek yok, çalıştırırken iletmeniz yeterli.

Hazır Script load-test.js

load-test.js adında bir dosya oluşturun ve içine şu kodu yapıştırın. Hedef adresi kendinizinkiyle değiştirin.

import http from 'k6/http'; import { check, sleep } from 'k6'; import { Trend, Rate, Counter } from 'k6/metrics'; const latency = new Trend('req_latency', true); const errors = new Rate('req_errors'); const ok = new Counter('req_ok'); export const options = { discardResponseBodies: true, thresholds: { req_errors: ['rate<0.02'], http_req_duration: ['p(95)<1500', 'p(99)<3000'], }, scenarios: { ramp: { executor: 'ramping-vus', startVUs: 0, stages: [ { duration: '1m', target: 10 }, { duration: '2m', target: 25 }, { duration: '2m', target: 50 }, { duration: '2m', target: 100 }, { duration: '2m', target: 200 }, { duration: '5m', target: 200 }, { duration: '1m', target: 0 }, ], gracefulRampDown: '30s', }, }, }; const TARGET = __ENV.TARGET_URL || 'https://stend.local/api/health'; export default function () { const res = http.get(TARGET, { timeout: '10s', tags: { name: 'target' } }); latency.add(res.timings.duration); const good = check(res, { 'status is 200': (r) => r.status === 200 }); errors.add(!good); if (good) ok.add(1); sleep(0.5); }

Senaryoyu Proxy Üzerinden Nasıl Çalıştırırsınız?

  1. Script'in bulunduğu klasörde bir terminal açın.
  2. Proxy adresi ve hedef ile ortam değişkenlerini ayarlayın. Linux ve macOS'ta değişkenleri dışa aktarma komutlarını çalıştırın.
  3. k6'yı script çalıştırma komutuyla başlatın.

Linux ve macOS'ta çalıştırma örneği:

export HTTP_PROXY=http://user:pass@proxy.proxeon.net:8000 export HTTPS_PROXY=http://user:pass@proxy.proxeon.net:8000 export TARGET_URL=https://stend.local/api/health k6 run load-test.js

Windows PowerShell'de değişkenler $env sözdizimiyle ayarlanır:

$env:HTTP_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:HTTPS_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:TARGET_URL="https://stend.local/api/health"; k6 run load-test.js

İpucu: discardResponseBodies parametresi, yanıt gövdelerinin bellekte saklanmasını devre dışı bırakır. Bu, üretecin kendisine binen yükü azaltır ve üretecin aşırı yüklenmesini proxy sınırıyla karıştırmamanıza yardımcı olur.

k6 Raporunu Okuma

Test bittikten sonra k6 bir özet çıkarır. Anahtar satırlara dikkat edin:

  • http_reqs - toplam istek sayısı ve parantez içinde ortalama RPS. Bu sizin bant genişliğiniz.
  • http_req_duration - avg, min, med, max ve p(90), p(95) yüzdelik dilimlerinin gösterildiği gecikmeler.
  • req_errors ve http_req_failed - hata oranı.
  • vus - anlık sanal kullanıcı sayısı.

thresholds satırı, belirlediğiniz eşiklerin geçilip geçilmediğini gösterecektir. Satırın yanında çarpı işareti varsa, eşik ihlal edilmiş demektir; yani bu yapılandırmada sınır zaten ulaşılmış veya aşılmıştır.

⚠️ Dikkat: stages içindeki target değerlerini kendi sisteminize göre ayarlayın. 200 VU değeri sadece bir örnektir. Hedefiniz veya proxy tarife limitiniz daha düşükse, örneğin 50'ye kadar daha mütevazı kademelerle başlayın.

Beklenen sonuç: test tamamlandı; RPS, yüzdelik dilimler ve hata oranıyla birlikte bir özet görüyorsunuz.

Olası sorunlar: tüm istekler başarısız oluyorsa, proxy değişkenlerini kontrol edin. Üreteç CPU'nun yüzde 100'ünü tüketiyorsa - VU sayısını azaltın veya testi daha güçlü bir makinede çalıştırın.

✅ Kontrol: k6 özetinde sıfır olmayan http_reqs görünüyor ve en azından ilk kademelerde hata oranı eşiğinizin altında.

Adım 4: JMeter - Aynı Senaryo, Test Planında Proxy Ayarlarıyla

Bu aşamanın amacı: JMeter'da proxy, kademeler ve metrik toplama ile eşdeğer bir plan oluşturmak.

İş Parçacığı Grubu Oluşturun

  1. Açık JMeter'da Test Plan öğesine sağ tıklayın.
  2. Add - Threads (Users) - Thread Group seçeneğini seçin.
  3. Number of Threads alanına maksimum iş parçacığı sayısını girin, örneğin 200.
  4. Ramp-up period alanına tam yüke çıkış süresini saniye cinsinden girin, örneğin 540, böylece k6'daki kademeli artışı tekrarlayın.
  5. Loop Count alanında Infinite (sonsuz) seçeneğini işaretleyin; süreyi bir zamanlayıcı ve zamanlayıcı ile belirleyeceğiz.

HTTP Request Defaults'ta Proxy Ayarı

Proxy'yi her istekte tanımlamak yerine bir kez tanımlayalım.

  1. Thread Group'a sağ tıklayın ve Add - Config Element - HTTP Request Defaults seçeneğini seçin.
  2. Açılan öğede proxy sunucusu ayarlarının bulunduğu sekmeyi bulun.
  3. Server Name or IP alanına (Proxy bloğunda) proxy'nin ana bilgisayarını girin, örneğin proxy.proxeon.net.
  4. Port Number alanına (Proxy) portu girin, örneğin 8000.
  5. Username ve Password alanlarına (Proxy) kullanıcı adınızı ve şifrenizi girin.

HTTP İsteğini Ekleyin

  1. Thread Group'a sağ tıklayın, Add - Sampler - HTTP Request seçeneğini seçin.
  2. Protocol alanına https yazın.
  3. Server Name or IP alanına hedefin alan adını yazın, örneğin stend.local.
  4. Path alanına yolu yazın, örneğin /api/health.
  5. Method alanında GET bırakın.

İstekler Arasına Gecikme Ekleyin

  1. HTTP Request'e sağ tıklayın ve Add - Timer - Constant Timer seçeneğini seçin.
  2. Thread Delay alanına k6'daki sleep'i tekrarlamak için 500 milisaniye girin.

Metrik Toplamayı Ayarlayın

  1. Thread Group'a sağ tıklayın ve Add - Listener - Summary Report ekleyin.
  2. Ayrıca Add - Listener - Aggregate Report ekleyin - yüzdelik dilimleri gösterir.
  3. Uzun testler için grafik dinleyicileri kullanmayın, bellek tüketirler. Bunun yerine sonuçları bir dosyaya kaydedin.

İpucu: Ağır testler için JMeter'ı terminalden grafik olmayan modda çalıştırın. Böylece üreteç kaynaklarını grafik çizmeye değil yüke harcar.

Grafik olmayan modda çalıştırma örneği:

jmeter -n -t plan.jmx -l results.jtl -e -o report

Burada -n grafik olmadan çalıştırır, -t plan dosyasını belirtir, -l ham sonuçların dosyasını, -e -o ise report klasöründe bir HTML raporu oluşturur.

JMeter Raporunu Okuma

report klasöründeki index.html dosyasını açın. Anahtar göstergeler:

  • Throughput - saniyedeki istek cinsinden bant genişliği.
  • Response Times Percentiles - gecikme yüzdelik dilimleri grafiği.
  • Error percentage - hata oranı.
  • Active Threads Over Time - paralelliğin nasıl arttığı.

⚠️ Dikkat: JMeter'da proxy kimlik doğrulaması bazen ek Temel yetkilendirme ayarı gerektirir. Toplu 407 hatası görüyorsanız, proxy bilgileriyle birlikte bir HTTP Authorization Manager öğesi ekleyin.

Beklenen sonuç: JMeter HTML raporu açılıyor ve throughput, yüzdelik dilimler ve hata oranını gösteriyor.

✅ Kontrol: JMeter'daki throughput ve yüzdelik dilim değerleri, aynı kademelerde k6 sonuçlarıyla karşılaştırılabilir. Küçük farklılıklar normaldir.

Adım 5: Proxy Sınırını İstemci Sınırından ve Sunucu Limitinden Ayırt Edin - Üç Kontrol

Bu aşamanın amacı: hangi düğümün darboğaz haline geldiğini kesin olarak belirlemek.

Bozulma gördüğünüzde kaynağını anlamak önemlidir. Üç kontrol testi yapın.

Kontrol 1: İstemciniz mi Zorlanıyor?

  1. Test sırasında üretici makinede sistem monitörünü açın.
  2. k6 veya JMeter sürecinin CPU ve RAM kullanımını izleyin.
  3. Linux'ta ulimit -n komutuyla açık dosya tanımlayıcı limitini kontrol edin.

Üreticinin CPU'su yüzde 100'e yakınsa veya tanımlayıcı limitine ulaştıysanız - suçlu istemcidir, proxy değil. Tanımlayıcı limitini artırın, VU sayısını azaltın veya daha güçlü bir makine kullanın.

İpucu: İstemci aşırı yüklenmesinin işareti, üreticinin CPU kullanımı artarken RPS sabitken gecikmelerin artmasıdır. Proxy'nin bununla bir ilgisi yoktur.

Kontrol 2: Hedef Sunucu mu Zorlanıyor?

  1. HTTP_PROXY ve HTTPS_PROXY değişkenlerini kaldırarak, proxy olmadan doğrudan kısa bir test çalıştırın.
  2. RPS ve yüzdelik dilimleri proxy üzerinden alınan sonuçlarla karşılaştırın.

Hem doğrudan hem de proxy üzerinden RPS sınırı neredeyse aynıysa - darboğaz hedef sunucudadır. Proxy yalnızca küçük bir sabit gecikme ekler.

⚠️ Dikkat: Doğrudan testi yalnızca kendi test ortamınıza karşı yapın. Teşhis amacıyla bile olsa izinsiz olarak başkalarının kaynaklarını yüklemeyin.

Kontrol 3: Proxy'nin Kendisini İzole Edin

  1. Kendi test ortamınızda anında 200 OK ile boş gövde döndüren hafif bir sahte uç (stub) kaldırın.
  2. Bu sahte uca karşı proxy üzerinden testi çalıştırın.

Sahte uç neredeyse anında yanıt verir, bu nedenle gecikmeler ve RPS sınırı artık esas olarak proxy ve ağ tarafından belirlenir. RPS özellikle sahte uçta bir tavana takılıyorsa - proxy sınırını buldunuz demektir.

Mantığı basit bir karar tablosuyla özetleyelim:

  • Üretici CPU'su yüksek, RPS artmıyor - istemci sınırı.
  • Doğrudan ve proxy üzerinden aynı - hedef sunucu sınırı.
  • Hızlı sahte uçta proxy üzerinden RPS tavana takıldı - proxy sınırı.

Beklenen sonuç: zincirinizi sınırlayan belirli düğümü adlandırıyorsunuz.

✅ Kontrol: Üç kontrolü de yaptınız ve darboğazın tam olarak nerede olduğunu gerekçelendirebiliyorsunuz.

Adım 6: Sonuçla Ne Yapmalı - İş Parçacıkları, Havuz ve Veri Çekme Süresi

Bu aşamanın amacı: test rakamlarını iş görevinizin pratik ayarlarına dönüştürmek.

Güvenli İş Parçacığı Sayısını Seçin

Bozulma noktasından önceki kademeyi alın. Diyelim ki 100 VU'da istikrarlı 180 RPS, p95 yaklaşık 900 ms ve hata oranı yüzde 1'in altında; 200 VU'da ise RPS artmadı, ancak p95 4 saniyeye fırladı. O zaman çalışma noktanız yaklaşık 100 VU'dur; güvenlik payı için 80-90 alın.

Proxy Havuz Boyutunu Hesaplayın

Bir proxy düğümü N paralel bağlantıyı istikrarlı bir şekilde tutabiliyorsa ve M eşzamanlı bağlantıya ihtiyacınız varsa, minimum havuz boyutu M bölü N'dir (yukarı yuvarlanır) artı pay. Yüzde 20-30'luk bir pay, yavaş yanıtların bazı bağlantıları meşgul ettiği anları kapsar.

İpucu: Her zaman havuz payı ekleyin. Gerçek yanıtlar sahte uçtan daha yavaştır, bu nedenle bağlantılar daha uzun süre tutulur ve fiili paralellik hesaplanandan daha yüksektir.

Veri Çekme Süresini Tahmin Edin

Formül basittir: saniye cinsinden süre, toplam istek sayısının istikrarlı RPS'ye bölünmesine eşittir. İstikrarlı 180 RPS'de 1.000.000 istek toplamanız gerekiyorsa, bu yaklaşık 5556 saniye, yani yaklaşık 1 saat 33 dakikadır (duraklamalar ve tekrarlar hariç).

  1. Çalışma kademesinden istikrarlı RPS'yi alın.
  2. Görevin toplam hacmini bu RPS'ye bölün.
  3. Başarısız isteklerin tekrarları ve duraklamalar için yüzde 15-20 ekleyin.

Anlaşılır olması için sözde kodla örnek hesaplama:

total = 1000000; rps = 180; base_sec = total / rps; final_sec = base_sec * 1.2; 












Yazar Hakkında







Roman Melnikov












Roman Melnikov


Technical Writer and System Administrator














İş Deneyimi:
Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.













Eğitim:

Bauman Moscow State Technical University. Information Systems and Technologies














Uzmanlık:


Technical Documentation
DevOps
System Administration
Linux
Docker and Kubernetes
CI/CD
Infrastructure Automation
Cloud Technologies
System Monitoring
Bash and Python Scripting























Makaleyi paylaşın: