Yük testi denince çoğu işletme sahibinin aklına bir komut satırı aracı ve ekranda akan sayılar gelir. “Ana sayfaya 1.000 istek attım, 200 döndü, sistem sağlam” cümlesi belki en yaygın ve en yanıltıcı teknik cümledir. Çünkü ana sayfan büyük olasılıkla önbellekten servis ediliyordur ve o test, sitenin gerçekten kırılacağı yerlere hiç dokunmamıştır. Gerçek kırılma noktası; sepete ekleme, ödeme başlatma ve e-pin teslim akışıdır.
Yük testinin amacı sistemin “dayandığını” kanıtlamak değildir. Amacı, sistemin nerede ve nasıl kırıldığını kampanya gecesinden önce öğrenmektir. İyi bir test seni gururlandırmaz, rahatsız eder; çünkü bilmediğin bir darboğazı yüzüne vurur. Bu yazıda kullandığın e-pin satış scripti için gerçekçi bir yük testi protokolünü, hangi senaryoyu nasıl kurgulayacağını ve çıkan sayıları nasıl okuyacağını sırayla kuracağız.
Neden Ana Sayfaya İstek Atmak Yük Testi Sayılmaz?
Bir e-pin sitesinde sayfalar maliyet açısından eşit değildir. Ana sayfa ve kategori sayfaları çoğunlukla önbelleklenebilir, veritabanına neredeyse dokunmaz. Buna karşılık oturum açma, bakiye yükleme, sepet, ödeme başlatma ve teslim adımları önbelleklenemez; her biri yazma işlemi yapar, kilit alır, üçüncü parti servise gider. Testini ucuz sayfalar üzerinden yaparsan ölçtüğün şey sunucunun statik dosya servis kapasitesidir, ticari kapasitesi değil.
Bunu düzeltmenin yolu senaryo bazlı test kurmaktır. Gerçek bir kullanıcı yolculuğunu adım adım taklit eden bir betik yazarsın: giriş yap, kategoriye gir, ürün sayfasını aç, sepete ekle, ödeme başlat, teslim sonucunu bekle. Her adım arasında 2-5 saniyelik düşünme süresi bırakırsın, çünkü gerçek insanlar makineler gibi ardı ardına tıklamaz. Bu düşünme süresini koymazsan test gerçekte olmayacak bir baskı üretir ve seni gereksiz panikle yanlış yatırıma sürükler.
Hangi Senaryoları Test Etmelisin ve Ağırlıkları Ne Olmalı?
Tek senaryo yeterli değildir; kampanya gecesinde trafiğin bir karışım hâlinde gelir. Sağlıklı bir karışım tipik olarak şöyledir: ziyaretçilerin büyük çoğunluğu gezinir, bir kısmı sepete ekler, daha küçük bir kısmı ödemeye gider. Bu oranları kendi analitiğinden almalısın. Dönüşüm oranın %2 ise testin de yaklaşık olarak bu oranı yansıtmalı. Dönüşümü %30 varsayan bir test, ödeme altyapını gerçekte olmayacak bir yükle döver ve sana “ödeme çöküyor” gibi yanlış bir alarm verir.
Yanında iki özel senaryo daha ekle. Birincisi tek ürün yığılması: kampanyaya konu olan tek bir e-pin ürününe eşzamanlı satın alma baskısı uygula; bu, stok kilidi kuyruğunu ölçer. İkincisi panel yükü: sen ve ekibin kampanya sırasında yönetim paneline girip sipariş listesi, stok ve rapor ekranlarını açacaksınız. Ağır rapor sorguları müşteri trafiğiyle aynı veritabanını kullandığı için kampanya gecesinde en sık gözden kaçan darboğaçlardan biridir. İyi bir dijital ürün satış yazılımı raporları ayrı ve hafif üretir, ama bunu ölçmeden bilemezsin.
| Senaryo | Trafik ağırlığı | Ölçtüğü katman | Hedef p95 | Başarısızlık işareti |
|---|---|---|---|---|
| Ana sayfa + kategori gezinme | %60 | Önbellek ve statik servis | 400 ms | Önbellek isabeti düşüyor |
| Ürün detay + arama | %20 | Veritabanı okuma ve indeks | 700 ms | Yavaş sorgu kaydı şişiyor |
| Sepete ekleme / oturum | %10 | Oturum yazma, kilit | 800 ms | Oturum çakışması, 5xx |
| Ödeme başlatma | %5 | Üçüncü parti API, zaman aşımı | 1500 ms | Bekleyen sipariş yığını |
| Tek ürüne yığılma | %3 | Stok kilidi kuyruğu | 1000 ms | Kilit zaman aşımı hatası |
| Yönetim paneli / rapor | %2 | Ağır toplama sorguları | 2000 ms | Tüm site birlikte yavaşlıyor |
Rampa Nasıl Kurulur: Testi Duvara Vurmadan Tırmandırmak
Yeni başlayanların en sık hatası testi en yüksek yükte başlatmaktır. Sıfırdan 500 eşzamanlı kullanıcıya bir saniyede çıkarsan her şey kırılır ve hangi seviyede kırıldığını öğrenemezsin. Doğru yöntem kademeli rampadır: 25 kullanıcıyla başla, iki dakika sabit tut, 50’ye çıkar, iki dakika tut, 100, 200 diye devam et. Her platoda p95 yanıt süresini ve hata oranını kaydet.
Aradığın şey dizüstü noktasıdır: yükü artırdığında verimin (saniyedeki başarılı işlem) artmayı bıraktığı, yanıt süresinin ise fırlamaya başladığı seviye. O nokta sistemin gerçek kapasitesidir. Kampanya hedefini bu noktanın %60-70 altında tutmalısın; çünkü gerçek trafik testin kadar düzenli gelmez. Rampa testinden sonra iki test daha yap: dayanıklılık testi (hedef yükün %60’ında 45-60 dakika, bellek sızıntısı ve bağlantı birikmesi için) ve ani sıçrama testi (hedefin iki katına 30 saniye, duyuru anını taklit eder ve toparlanma süresini ölçer).
Yük testinde ilk kırılan bileşenlerin dağılımı
- İndekssiz / ağır sorgular 40%
- İşçi sayısı ve kuyruk taşması 30%
- Üçüncü parti API zaman aşımı 20%
- Disk ve oturum yazma 10%
Hangi Sayılara Bakacaksın? Ortalama Yanıt Süresi Seni Kandırır
Test çıktısında en cazip sayı ortalama yanıt süresidir ve en işe yaramaz olan da odur. 100 isteğin 90’ı 200 ms’de, 10’u 8 saniyede dönerse ortalama 980 ms görünür; oysa müşterilerinin %10’u siteyi terk etmiştir. Bu yüzden karar verirken p95 ve p99 değerlerine bak: isteklerin %95’i ve %99’u hangi sürede tamamlanıyor. p95 hedefin sayfa tipine göre 400-1500 ms bandında olmalı.
Yanında mutlaka izlemen gereken dört sayı daha var: hata oranı (%1 üzeri kırmızı çizgi), verim yani saniyedeki başarılı işlem sayısı, eşzamanlı veritabanı bağlantısı ve sunucu tarafında kuyruk uzunluğu. Testi yalnızca test aracının çıktısıyla değerlendirmek yarım iş olur; test sürerken sunucuda da CPU, bellek, disk bekleme ve yavaş sorgu kaydını topla. Kırılmanın sebebini ancak iki tarafı yan yana koyarak bulabilirsin.
Ödeme adımını test ederken sağlayıcının sanal/sandbox ortamını kullan. Canlı uçlara yüzlerce sahte istek atmak hesabının askıya alınmasına yol açabilir. Aynı şey e-pin tedarikçi API’leri için de geçerlidir.
Test Sonrası Ne Yapacaksın: Sayıları Aksiyona Çevirmek
Rapor okumak kolay, karar vermek zordur. Sonuçları üç kovaya ayır. Birinci kova kod ve sorgu düzeltmeleri: yavaş sorgu kaydında çıkan indekssiz sorgular, N+1 döngüleri, teslim işlemi içine sıkışmış mail gönderimi. Bu kova en ucuz ve en yüksek getirili olandır; genelde tek bir indeks p95’i yarıya indirir. İkinci kova yapılandırma: işçi sayısı, bağlantı havuzu, önbellek süreleri, zaman aşımı değerleri. Üçüncü kova donanım ve ilk ikisi tükenmeden buraya para harcamamalısın.
Düzeltmeyi yaptıktan sonra testi aynı senaryo ve aynı rampa ile yeniden koş. Karşılaştırılabilir olmayan test, test değildir; bu yüzden senaryo dosyanı ve rampa planını sürüm kontrolünde tut. Bir e-pin yazılımı kurulumunda bu döngüyü üç kez tekrarlamak, çoğu zaman sunucu paketini büyütmeden kapasiteyi iki katına çıkarır. Pinova’nın hangi modüllerinin önbelleğe alınabilir, hangilerinin yazma yoğun olduğunu özellikler sayfasından inceleyip senaryonu buna göre kurabilirsin.
| Test adımı | Süre | Kabul kriteri | Zorunluluk |
|---|---|---|---|
| Kopya (staging) ortam hazırlandı | 1 gün | Canlıyla aynı sürüm ve veri hacmi | Zorunlu |
| Gerçekçi senaryo betiği yazıldı | 2-4 saat | 6 adımlı yolculuk, düşünme süresi var | Zorunlu |
| Ödeme ve tedarikçi uçları sandbox’a çevrildi | 30 dk | Canlı uca tek istek gitmiyor | Zorunlu |
| Kademeli rampa testi | 20-30 dk | Dizüstü noktası tespit edildi | Zorunlu |
| Dayanıklılık testi | 45-60 dk | Bellek ve bağlantı sayısı düz | Önerilen |
| Ani sıçrama testi | 5 dk | 2 dk içinde toparlanma | Önerilen |
| Sunucu tarafı metrikler toplandı | test boyunca | CPU, RAM, DB, yavaş sorgu kaydı | Zorunlu |
| Düzeltmeler uygulandı | 1-2 gün | Kod ve yapılandırma kovaları bitti | Zorunlu |
| Doğrulama testi tekrar koşuldu | 30 dk | p95 en az %30 iyileşti | Zorunlu |
| Sonuçlar ve hedef rps belgelendi | 1 saat | Kampanya planına yazıldı | Önerilen |
Test etmeye değer bir altyapıyla başla
Pinova, yük altında davranışı öngörülebilir olacak şekilde tasarlanmış bir e-pin satış yazılımıdır: hafif sorgular, ayrılmış rapor katmanı ve kısa süreli stok kilitleri. Testin sonucu sürpriz değil, doğrulama olsun.
Yük testini canlı sitemde yapabilir miyim?
Yapılabilir ama ancak trafiğin en düşük olduğu saatte, düşük yükte ve ödeme uçları sandbox’a alınmış hâlde. Gerçek kapasite testini her zaman canlının bire bir kopyasında yapmak doğrusudur; aksi hâlde test müşterini kaybettirir.
Kaç eşzamanlı kullanıcıya kadar test etmeliyim?
Kampanya için hesapladığın tepe hedefin en az iki katına kadar. Amaç hedefi geçmek değil, kırılma noktasını görmek; kırılmayı görmediysen testi yeterince zorlamadın demektir.
Testte hata oranı sıfır çıkmalı mı?
Hayır. Yüksek yükte %0,5’e kadar hata normaldir. Kırmızı çizgi %1’dir. Önemli olan hataların türü: zaman aşımı ve 5xx ciddidir, kilit yeniden denemesi görece iyidir.
Yük testi için hangi araca ihtiyacım var?
Basit senaryolar için hafif komut satırı araçları yeterlidir; çok adımlı, oturum taşıyan yolculuklar için betik yazılabilen bir araç gerekir. Araç seçiminden daha önemlisi senaryonun gerçekçi olması ve sunucu tarafı metrikleri aynı anda toplamandır.
Yük testi bir kere yapılıp rafa kaldırılan bir tören değil, her büyük kampanyadan önce tekrarlanan kısa bir alışkanlıktır. Senaryo dosyanı bir kez yazarsan sonraki testler yarım saatini alır ve her seferinde altyapının nerede durduğunu net olarak bilirsin. Kendi kurulumunun teslim akışını, panel sorgularını ve ödeme adımlarını bu gözle incelemek istersen canlı demo üzerinden tüm ekranları dolaşabilir, ardından paketleri kendi trafik hedefinle karşılaştırabilirsin.