Şunu açık konuşayım: yük testi denince çoğu kişinin aklına önce terminal, sonra agent, ardından saatlerce sürecek kurulum geliyor. Hani “bir saniye, ben sadece bu API kaç istek kaldırıyor onu görmek istiyordum” dediğiniz an — işler aniden büyüyor. Ben de tam bu yüzden tarayıcı içinde çalışan, stateless bir API yük test aracına ayrı bir ilgi duydum; çünkü bazen ihtiyacınız olan şey devasa bir performans platformu değil, sadece hızlı, temiz. Çabuk cevap veren bir şey.
Geçen yıl İstanbul’daki küçük bir SaaS ekibiyle çalışırken benzer bir tabloya denk geldim. İç servislerden biri ara ara yavaşlıyordu. Ama ekip elindeki klasik load testing düzenini ayağa kaldırana kadar sorun zaten kaybolmuştu. O an şunu anladım: “kurulumu yarım saat süren test”, çoğu zaman gerçek dünyada geç kalmış test demek.
Neden Tarayıcı? Neden Şimdi?
Bakın şimdi, tarayıcı tabanlı yük testi kulağa ilk başta biraz tuhaf geliyor. “Ciddi performans testi yapılacaksa neden browser?” diye soran çok olur — haklılar da açıkçası. Ama mesele her zaman binlerce eşzamanlı bağlantıyı ezmek değil; bazen sadece o anki davranışı görmek yeterli. En çok da geliştirme aşamasında ya da QA tarafında hızlı geri bildirim almak istiyorsanız tarayıcı baya iş görüyor.
İşte tam da bu noktada devreye giriyor.
Ne yalan söyleyeyim, Ben 2024’ün Kasım ayında Ankara’da bir demo ortamını test ederken bunu kendi gözümle gördüm. Sunucu tarafı tertemiz görünüyordu. Ama front-end üzerinden atılan istekler beklenenden farklı davranıyordu; çünkü header sırası, token yenileme akışı. Bazı CORS detayları masaüstü istemcilerde yakalanmayan ufak farklar yaratıyordu, ve bunları ancak browser’dan geçince fark edebildik. Browser burada “gerçek kullanıcıya yakın” bir davranış veriyor. İşin aslı şu ki bu, bazen laboratuvar cihazlarından çok daha değerli oluyor.
Bir de şu var. Kurulum yoksa sürtünme azalıyor. Agent mı kuracaksınız? Credential mı saklayacaksınız? Test tanımlarını mı backend’e yazacaksınız? Kısa süreli denemeler için bunların hepsi fazladan yük — özellikle küçük ekiplerde bu iş büyüdükçe büyüyor. Kimse istemediği halde mini bir altyapı projesine dönüşüyor.
Durun, bir saniye. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Tarayıcının sağladığı gizli avantajlar
Doğrusu, Dur bir saniye, önce şunu söyleyeyim: tarayıcı her şeyi çözmüyor. Dağıtık sistemlerin yerini tutmaz. Ama yine de fena olmayan birkaç artısı var; HTTP yığını olgun, async istek yönetimi doğal geliyor ve istemci tarafındaki gerçek gecikme koşullarını doğrudan görüyorsunuz.
- Sıfır kurulumla çalışıyor — bunu es geçmeyin
- Kullanıcıya yakın trafik üretiyor
- Token ve header davranışını doğal şekilde yansıtıyor
- Kısa ömürlü testlerde temizlik derdi çıkarmıyor
Stateless Tasarım Neyi Değiştiriyor?
Konu stateless olunca iş biraz daha temizleşiyor. Her test oturumu yalnızca bulunduğunuz seans boyunca (söylemesi ayıp) yaşıyor — giriş yapma yok, hesap bağlama yok, arka planda saklanan test geçmişi yok. Basit geliyor. Ama pratikte bu küçük şey inanılmaz rahatlık sağlıyor (ki bu çoğu kişinin gözünden kaçıyor) Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Bunu geçen ay İzmir’deki bir fintech ekibiyle konuşurken tekrar düşündüm. Onlar üçüncü taraf ödeme API’lerini test ederken veri bırakmak istemiyordu; hem güvenlik hem uyumluluk açısından gayet haklıydılar. Stateless yaklaşım tam burada nefes aldırıyor, çünkü sistem “ben sadece UI veriyorum” diyerek kenarda duruyor — orkestrasyon yapmıyor, oturum taşımıyor, hayatınıza girmiyor. Bu konuyla ilgili Muse’un Akıllı Uyandırma Hamlesi: Alarmı Beyniniz Seçiyor yazımıza da göz atmanızı tavsiye ederim.
Ama açıkçası bu modelin güzel yani kadar sınırı da var. Güven veriyor, tamam. Kalıcılık sunmuyor — işte sorun burada. Uzun vadeli trend analizi veya geçmiş karşılaştırmaları için tek başına yeterli değil (inanın bana). Sürekli rapor isteyen ekiplerde eksik kalabilir (kendi tecrübem). Nasıl desem… kısa koşular için ideal, maraton için değil.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Klasik load testing stack’i | Büyük ölçek, ayrıntılı raporlama | Kurulum ve bakım maliyeti yüksek |
| Browser-based stateless tool | Sıfır kurulum, hızlı geri bildirim | Aşırı yüksek throughput için uygun değil |
Küçük startup ile enterprise aynı şeye bakmıyor
Bunu yaşayan biri olarak söyleyeyim, Küçük bir startup için mesele çoğu zaman “şu endpoint bugün niye takılıyor?” sorusudur. Tek soru, tek cevap, hızlıca. Enterprise tarafta ise konu bambaşka olur; SLA’ler, dağıtık ajanlar, bölgesel trafik simülasyonu derken iş uzar gider ve kimse “şimdi tarayıcıdan bi’ bakayım” demez. O yüzden tek araç herkese uymaz — bu kadar basit aslında.
Tarayıcı içinden yapılan stateless yük testi devasa kapasiteyi ölçmez; ama hızlı karar vermek istediğiniz anlarda şaşırtıcı derecede net sinyal verir.
İstekleri Tarayıcıda Nasıl Üretiyor?
Mantık aslında sade. Async batch’ler gönderiliyor, concurrency promise pool ile kontrol ediliyor ve sonuçlar anlık toplanıyor. Karmaşık sihirbazlık yok. İlginç, değil mi? Daha çok iyi organize edilmiş küçük görev grupları var gibi düşünün — pek de göz korkutucu değil. Daha fazla bilgi için İki Site, Bir Saldırı: Chime ve Pinterest Neden Düştü? yazımıza bakabilirsiniz. Daha fazla bilgi için Planeta Libre: Ñoño Bloglarının Sessiz Buluşma Noktası yazımıza bakabilirsiniz.
Şunu söyleyeyim, Bunu ilk kez kendi lab ortamımda denediğimde — tarih notu düşeyim, Ocak 2025’te Kadıköy’de ev ofisimde — beklediğimden daha düzgün çalıştı. Tahmin eder misiniz? En hoşuma giden şey şu oldu: response time’lar ve hata kodları client-side’da canlı akıyordu; sayfa kapanınca her şey gidiyor tabii, ama o kısa pencere içinde oldukça net veri elde ediyorsunuz, şaşırdım açıkçası (en azından benim deneyimim böyle)
// Basit mantık örneği
const pool = new PromisePool({ concurrency: 10 });
for (const request of requests) {
pool.add(async () => {
const started = performance.now();
const res = await fetch(request.url, request.options);
const ended = performance.now();
return {
status: res.status,
durationMs: ended — started
};
});
}Tam burada önemli nokta şu: load tester’ın amacı sadece çok istek atmak değil. Gecikme dağılımını görmek, hata oranlarını yakalamak, darboğazın nerede olduğunu anlamak gerekiyor — bunlar olmadan sayı üretmiş olursunuz sadece, ölçüm değil.
Neleri iyi yapıyor?
İtiraf edeyim, Peki ne zaman parlıyor? Authenticated endpoint’lerde token’ın gerçekten nasıl davrandığını görmek istediğinizde işe yarıyor. Bir de rate limit sınırlarını kısa sürede yoklamak için ideal sayılır. Browser’dan çıkan trafik çoğu zaman prod’a daha yakın hissediliyor — bunu yaşayana kadar tam anlamak zor.
- API gateway testi: Header ve auth akışı doğal kalır.
- Üçüncü taraf servis: Kontrol sizde olmayan uçlarda hızlı sinyal verir.
- Düşük riskli QA: Kısa süreli deneylerde çeviklik sağlar. (bence en önemlisi)
- Erişim analizi: İstemci kaynaklı gecikmeleri görmenize yardım eder.
Nerede Hayal Kırıklığı Yaşatabilir?
Açık konuşayım. Bu yaklaşımın en zayıf yani ölçek meselesi. Fena değil dediğim yer burası zaten — ama bazı senaryolarda yeterince güçlü olmuyor. Eğer hedefiniz yüzlerce eşzamanlı kullanıcıyı farklı bölgelerden simüle etmekse, browser tabanlı çözüm çabuk daralıyor; bunu umarak gelirseniz hayal kırıklığı kaçınılmaz.
Beni en çok zorlayan kısım raporlama tarafıydı desem yalan olmaz. Kurumsal projelerde insanlar grafikleri sever; dashboard isterler, trend isterler, geçen ayki verilerle kıyaslamak isterler (inanın bana). Bu tür araçlarda odak genelde anlık cevap olduğu için tarihsel kıyaslama ikinci plana düşüyor. Hızlıca “şu an ne oluyor” sorusunu cevaplayabiliyor ama “geçen haftaya göre nasıl” sorusuna pek giremiyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
