Ş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 önü 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 ölür — 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 hâlde 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, Dür 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 işe konu bambaşka ölür; 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 mısınız? 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.
Sıkça Sorulan Sorular
Tarayıcı tabanlı yük testi gerçekten “gerçek kullanıcı” trafiğini yansıtır mı?
Evet, büyük ölçüde yansıtır. Çünkü istekler tarayıcının HTTP yığını, CORS kuralları, header/tokene bağlı akışlar ve bağlantı davranışlarıyla birlikte gider. Ben özellikle token yenileme ve header sırası gibi “küçük görünen” farkların performansı etkilediği senaryolarda tarayıcıyı çok değerli buldum. Yine de bu, uçtan uca bir dağıtık sistem simülasyonu yerine “istemciye yakın” bir test yaklaşımıdır.
Sıfır kurulum derken tam olarak ne kastediliyor?
Genelde tarayıcıda çalışan bir araçla test başlatıp sonucu hızlıca izlemek kastediliyor. Yani agent kurma, ayrı bir runtime ayağa kaldırma veya karmaşık credential yönetimi gibi sürtünmeler azalıyor. Kısa süreli QA denemelerinde özellikle hayat kurtarıyor; çünkü testin kendisi kadar “hazırlık süresi” de maliyet olabiliyor. Benim deneyimimde, ekipler en çok bu bekleme ve kurulum döngüsünde zaman kaybediyor.
Bu tarz testler kaç istek/saniye kaldırır, “ciddi” performans testi yerine geçer mi?
Bu araçların gücü genelde hızlı doğrulama ve istemci davranışını yakalamaktır. Çok yüksek ölçekli, dağıtık load üretimi gerektiren senaryolarda ise klasik load/benchmark yaklaşımları daha uygun olur. Ama API gateway’ler, rate limit’ler ve üçüncü taraf servisler gibi noktalarda “gerçekten istemci gibi mi gidiyor?” sorusunu cevaplamak için çok iyi bir başlangıçtır. Ben bunu çoğu zaman ilk teşhis için kullanıyorum; sonra gerekirse daha ölçekli testlere geçiyorum.
Tarayıcıda test yapınca CORS veya token akışı kaynaklı hatalar daha mı sık görünür?
Evet, çünkü tarayıcı güvenlik politikaları (CORS gibi) ve kimlik akışları (token yenileme, header’lar) gerçekçi şekilde devreye girer. Bu da bazı hataların sadece browser’da ortaya çıkmasına yol açabilir. Örneğin masaüstü istemciyle çalışan bir akış, tarayıcıda farklı header sırasi veya preflight davranışı yüzünden sapabilir. Bu yüzden tarayıcı testi, “neden prod’da farklı davranıyor?” sorusuna hızlı yanit verir.
Stateless bir yaklaşım ne sağlar, neden önemli?
Stateless yaklaşım, test süresince sunucu tarafında oturum/kalıcılık yükünü gereksiz yere büyütmez. Böylece ölçüm daha “temiz” olur ve sonuçlar daha öngörülebilir hale gelir. Kısa ömürlü testlerde ayrıca temizlik/rollback derdi azalır; çünkü test için özel veri üretip sonra uğraşmanız gerekmez. Yine de uygulamanız gerçekten stateful davranıyorsa, onu ayrıca test etmek gerekir.
Kaynaklar ve İleri Okuma
Azure’da İzleme için En İyi Uygulamalar
Azure Load Testing (Dokümantasyon)
Azure API Management Gateway Genel Bakış
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.
