E-Ticaret Sitesinde Kampanya Öncesi Yük Testi Nasıl Yapılır?

Kampanya öncesi yük testi, geçen yılın tepe trafiğinden çıkardığınız hedefi gerçek bir alışveriş yolunu taklit eden betikle, kademeli artırarak siteye uygulamaktır. Ana sayfa, kategori, ürün, sepete ekleme ve ödeme adımlarını k6, JMeter ya da Locust gibi bir araçla senaryolaştırırsınız. Testi sunucunun kendisinden değil ayrı bir makineden, mümkünse hazırlık ortamında çalıştırırsınız. p95 yanıt süresi, hata oranı, saniyedeki istek sayısı ve sunucu kaynaklarını izler, önceden yazdığınız eşiklerde durursunuz. Yalnız kendi sisteminizi test edin. Paylaşımlı hostingte ya da Cloudflare arkasındaysanız önce sağlayıcınızla konuşun.

Önce kural: yalnız kendi sisteminizi test edin

Yük testi aracı ile hizmet engelleme saldırısı arasındaki teknik fark, trafiği kimin, kimin izniyle gönderdiğidir. Sahibi olmadığınız ya da yazılı izin almadığınız bir sisteme yük göndermek saldırı olarak değerlendirilebilir ve hukuki sorumluluk doğurabilir. Bu kural sitenizin içindeki üçüncü taraf servisleri de kapsar. Ödeme kuruluşunun canlı API'si, kargo firmasının fiyat servisi, pazaryeri entegrasyonu, analitik ve reklam etiketleri sizin sisteminiz değildir. Testte bunların yerine test (sandbox) ortamlarını kullanın ya da o adımları senaryodan çıkarın.

İşin iyi tarafı şu: k6, JMeter ve Locust protokol düzeyinde çalışır, yani tarayıcı gibi sayfadaki JavaScript'i çalıştırmaz. Siz hangi adresleri yazdıysanız yalnız onlara istek gider. Sayfaya gömülü üçüncü taraf betikler kendiliğinden yüklenmez. Bedeli de var: tarayıcının arka planda attığı AJAX isteklerini, mesela ödeme sayfasındaki update_order_review çağrısını, betiğe sizin eklemeniz gerekir.

Paylaşımlı hostingte

Paylaşımlı sunucuda aynı makineyi başka müşteriler de kullanır. Yaptığınız test onların sitesini de yavaşlatır ve çoğu sağlayıcının kullanım koşullarına takılır. Üstelik sonuç büyük ihtimalle sizin uygulamanızı değil hesabınıza tanımlı limitleri ölçer. Tek IP'den gelen yoğun istek sunucunun güvenlik duvarına ya da hız sınırına da takılabilir, test birkaç dakika içinde 403 ya da 429 yanıtlarıyla biter. Bu yüzden testten önce sağlayıcınıza tarih ve saati, yükün geleceği IP adresini, hedeflediğiniz en yüksek yükü ve süreyi yazın. Siteniz Netx'te barındırılıyorsa bu bilgileri Netx müşteri panelinden destek talebiyle iletin.

Cloudflare ya da başka bir koruma katmanı arkasında

Cloudflare'in saldırı simülasyonu belgesi, kendi hesabınızdaki ve sizin adınıza kayıtlı mülklere yönelik testler için Cloudflare'den izin almanız gerekmediğini söylüyor. Başkalarıyla paylaşılan mülkler bu kapsamın dışında. Pratik sorun başka: DDoS koruması, WAF, hız sınırlama ve bot yönetimi kuralları test trafiğini saldırı sayıp engelleyebilir ya da doğrulama sayfasına düşürebilir. O durumda ölçtüğünüz şey sitenizin kapasitesi değil, koruma katmanının tepkisidir. Cloudflare hesabını bir ajans ya da sağlayıcı yönetiyorsa önce onlarla konuşun. Kendiniz yönetiyorsanız test IP'nize hangi kuralların uygulanacağına önceden karar verin ve kuralı test bitince geri alın.

Hedefi geçmiş veriden çıkarın

"Bin kişi gelsin bakalım" diye başlayan test, neyi kanıtladığını bilmeyen bir testtir. Hedef, geçen kampanyanın ya da yılın en yoğun gününün verisinden gelmeli. Analitik aracınızda en yoğun saati bulun ve üç değeri not edin: o saatteki oturum sayısı, ortalama oturum süresi ve oturum başına sayfa görüntüleme. Çerez onayı vermeyen ziyaretçiler analitikte görünmeyebilir, gerçek trafik daha yüksek olabilir. Sunucu erişim günlüğü bu açığı kapatır. Aşağıdaki komut, standart (combined) biçimdeki bir erişim günlüğünde dakika başına istek sayısını çıkarır ve en yoğun dakikaları listeler:

awk '{print $4}' access.log \
  | cut -d: -f1-3 \
  | sort | uniq -c \
  | sort -rn | head -20

Çıktının ilk sütunu istek sayısı, ikinci sütunu [gün/ay/yıl:saat:dakika biçimindeki zamandır. Bu sayı görseller ve CSS dahil bütün istekleri içerir, dinamik sayfa yükünü görmek için grep -v ile statik dosya uzantılarını eleyebilirsiniz.

Varsayımsal senaryo: geçen yılın kampanya gününde en yoğun saatte 6.000 oturum var, ortalama oturum 4 dakika, oturum başına 6 sayfa görüntüleniyor. Bu yıl pazarlama ekibi %50 büyüme bekliyor.

Son satırdaki çarpan bir varsayım. Kendi erişim günlüğünüzde en yoğun dakikanın saatlik ortalamaya oranına bakarak gerçek değeri bulun. Test hedefini bu sayının biraz üstüne koyun, çünkü amaç sınırın nerede olduğunu görmek.

Senaryoları gerçek alışverişe benzetin

Sık yapılan hata, tek bir adresi saniyede yüzlerce kez istemektir. Ana sayfa sayfa önbelleğinden gelir, sonuç harika çıkar ve kampanya günü sepet adımı çöker. Gerçek ziyaretçilerin çoğu sepete hiç ürün eklemez, ekleyenlerin bir kısmı ödemeye geçer. Önbelleğe giren sayfalarla giremeyenlerin oranı bu dağılımla belirlenir. Analitikteki dönüşüm hunisinden yaklaşık bir dağılım çıkarın. Örneğin her 100 ziyaretçiden 30'u sepete ekliyor, 10'u ödeme sayfasına geçiyor. Bu oranlar da varsayımdır, kendi verinizle değiştirin.

Üç ayrıntı sonuçları gerçekçi kılar. Birincisi, her sanal kullanıcı farklı ürün ve kategori adresleri gezmeli. Tek ürün sayfası hep önbellekten gelir, katalogdaki yüzlerce sayfa öyle değildir. İkincisi, adımlar arasında düşünme süresi (think time) bırakın, gerçek insanlar art arda tıklamaz. Üçüncüsü, sepete ekleme adımından sonra oturum çerezi taşınmalı. Sepeti dolu kullanıcının istekleri sayfa önbelleğini atlar, testin asıl yükü buradan gelir.

Ödeme adımı ayrı bir karar ister. Sipariş oluşturan bir senaryo veritabanına gerçek kayıt yazar, stok düşürür, e-posta tetikler. Bunu yalnız hazırlık ortamında, ödeme yöntemini test kipine (ya da kapıda ödeme gibi çevrimdışı bir yönteme) alarak ve e-posta ile entegrasyonları kapatarak yapın. Canlı sitede test sırasında sipariş oluşturmayın, ödeme sayfasını görüntülemekle yetinin.

Araç seçimi: k6, JMeter, Locust

Üçü de iş görür. Seçimi ekibinizin hangi dili rahat okuduğu belirlesin.

Üçünün de komut satırından çalıştırılışı şöyle:

k6 run kampanya.js

jmeter -n -t kampanya.jmx -l sonuc.jtl -e -o rapor

locust -f kampanya.py --headless \
  -u 150 -r 2 -t 20m \
  -H https://hazirlik.ornek.com.tr --csv sonuc

JMeter'in kendi belgesi açıkça söylüyor: grafik arayüz yalnız planı hazırlamak içindir, yük testini -n ile komut satırı kipinde çalıştırın. -e -o test bitince HTML raporu üretir ve -o ile verilen klasör boş ya da hiç yok olmalıdır. Locust'ta -u en yüksek eşzamanlı kullanıcı sayısını, -r saniyede kaç kullanıcı ekleneceğini, -t süreyi belirler.

Basit bir k6 betiği

Aşağıdaki betik bir alışveriş yolunu taklit eder: ana sayfa, kategori, ürün ve kullanıcıların yaklaşık üçte birinde sepete ekleme, sepet ve ödeme sayfasını görüntüleme. Adresler ve ürün kimlikleri örnektir. Kendi mağazanızdaki basit (varyasyonsuz) ürünlerin kimliklerini yazın, çünkü varyasyonlu ürün ?add-to-cart= ile varyasyon bilgisi olmadan sepete eklenmez.

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.BASE_URL || 'https://hazirlik.ornek.com.tr';
const KATEGORILER = ['/urun-kategori/ayakkabi/', '/urun-kategori/canta/'];
const URUNLER = [
  { yol: '/urun/ornek-urun-1/', id: 101 },
  { yol: '/urun/ornek-urun-2/', id: 102 },
];

export const options = {
  userAgent: 'ornek-magaza-yuk-testi/1.0',
  stages: [
    { duration: '5m', target: 50 },
    { duration: '5m', target: 50 },
    { duration: '5m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '5m', target: 150 },
    { duration: '5m', target: 150 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_failed: [
      { threshold: 'rate<0.02', abortOnFail: true, delayAbortEval: '1m' },
    ],
    http_req_duration: ['p(95)<1200'],
    'http_req_duration{name:sepet}': ['p(95)<1500'],
    'http_req_duration{name:odeme}': ['p(95)<2000'],
  },
};

function sec(dizi) {
  return dizi[Math.floor(Math.random() * dizi.length)];
}

export default function () {
  let r = http.get(`${BASE}/`, { tags: { name: 'anasayfa' } });
  check(r, { 'anasayfa 200': (x) => x.status === 200 });
  sleep(2 + Math.random() * 3);

  r = http.get(BASE + sec(KATEGORILER), { tags: { name: 'kategori' } });
  check(r, { 'kategori 200': (x) => x.status === 200 });
  sleep(2 + Math.random() * 3);

  const urun = sec(URUNLER);
  r = http.get(BASE + urun.yol, { tags: { name: 'urun' } });
  check(r, { 'urun 200': (x) => x.status === 200 });
  sleep(3 + Math.random() * 4);

  if (Math.random() < 0.3) {
    r = http.get(`${BASE}/?add-to-cart=${urun.id}`, { tags: { name: 'sepete_ekle' } });
    check(r, { 'sepete ekle 200': (x) => x.status === 200 });
    sleep(2);
    r = http.get(`${BASE}/sepet/`, { tags: { name: 'sepet' } });
    check(r, { 'sepet 200': (x) => x.status === 200 });
    sleep(3);
    r = http.get(`${BASE}/odeme/`, { tags: { name: 'odeme' } });
    check(r, { 'odeme 200': (x) => x.status === 200 });
  }
  sleep(5);
}

Birkaç satırın ne işe yaradığına bakalım. stages sanal kullanıcı (VU) sayısını beşer dakikalık basamaklarla 50, 100 ve 150'ye çıkarır, her basamakta beş dakika bekler. Bu sayılar örnektir, hedef hesabınızdan türetin. tags: { name: ... } her isteği bir sayfa türüne bağlar, böylece özet raporda sepet ve ödeme sürelerini ayrı görürsünüz. thresholds bölümündeki ilk eşik, hata oranı %2'yi aşarsa testi kendiliğinden durdurur. delayAbortEval bu değerlendirmeyi testin ilk dakikasından sonraya bırakır, ısınma sırasındaki birkaç hata testi erkenden kesmez. Eşik söz dizimi k6 belgesinin eşikler bölümünde anlatılıyor. Eşiklerden biri tutmazsa k6 sıfırdan farklı bir çıkış koduyla biter. k6 her sanal kullanıcı için ayrı bir çerez kavanozu tutar ve varsayılan olarak her döngüden sonra sıfırlar, yani her döngü sepeti boş yeni bir müşteri gibi davranır. userAgent ise test trafiğini erişim günlüğünde ve analitikte ayırt etmenizi kolaylaştırır.

Betiği hedef adresi dışarıdan vererek çalıştırın:

k6 run -e BASE_URL=https://hazirlik.ornek.com.tr kampanya.js

Hedefiniz eşzamanlı kullanıcıdan çok saniyedeki istek sayısıysa k6'nın ramping-arrival-rate yürütücüsü daha uygun düşer. Bu yürütücü, yeterli sanal kullanıcı ayrıldığı sürece sunucu yavaşlasa bile yeni döngüleri belirlediğiniz hızda başlatır ve kuyruğun nasıl büyüdüğünü gösterir.

Testi nereden ve hangi ortamda çalıştırmalı?

Yük üreten araç ile test edilen site aynı sunucuda olmamalı. Aynı makinede çalışan k6 da işlemci ve bellek tüketir, ölçtüğünüz şey iki yükün kavgası olur. Ayrı bir bilgisayar ya da geçici bir sanal sunucu kullanın. Ziyaretçileriniz Türkiye'deyse yükü de Türkiye'deki bir ağdan üretmek gecikmeyi gerçekçi tutar. Yük üreten makinenin işlemcisi test boyunca %80'in üstüne çıkıyorsa sonuçlarınız sitenizi değil o makineyi ölçüyordur. Bu durumda yükü iki makineye bölün.

Ortam seçimi bir ödünleşimdir. Hazırlık ortamı canlıyla aynı donanımda, aynı veri hacminde ve aynı eklentilerle çalışıyorsa en güvenli yer orasıdır. Daha küçük bir sunucuda duran hazırlık kopyası ise sınırı olduğundan erken gösterir. Canlıda test yapacaksanız en düşük trafikli saati seçin, yalnız okuma yapan adımlarla (gezinme, sepet ve ödeme sayfasını görüntüleme) sınırlı kalın ve testi durduracak kişiyi önceden belirleyin.

Sayfa önbelleğini de hesaba katın. Kampanya başlarken fiyatları güncellediğinizde önbellek temizlenir ve ilk dakikalar soğuk önbellekle karşılanır. Bir turu önbelleği temizledikten hemen sonra, bir turu önbellek ısındıktan sonra koşun. İkisi arasındaki fark size kampanyanın ilk beş dakikasının neye benzeyeceğini söyler.

Kademeli artış ve durdurma ölçütleri

Yükü bir anda vermek yerine basamak basamak artırın ve her basamakta sistemin dengeye oturmasını bekleyin. Yanıt süresi bir basamakta sabit kalıp sonrakinde sıçrıyorsa sınırın o iki basamak arasında olduğunu anlarsınız. Testten önce, kâğıda ya da ortak bir belgeye şu durdurma ölçütlerini yazın:

• Hata oranı %2'yi aşarsa (betikteki otomatik eşik)
• Sepet ya da ödeme sayfasının p95 süresi hedefin iki katına çıkar ve basamak boyunca düşmezse
• 403, 429 ya da doğrulama sayfası dönmeye başlarsa, yani bir koruma katmanı devreye girdiyse
• Sunucuda takas (swap) kullanımı başlar ya da bellek tükenme uyarısı gelirse
• Canlı testte gerçek müşterilerden hata ya da yavaşlık bildirimi gelirse
• Yük üreten makinenin kendisi doyarsa

k6'yı elle durdurmak için Ctrl+C yeterli. Durdurduğunuz anın saatini not edin, sunucu tarafındaki grafiklerle eşleştirirken lazım olacak.

İzlenecek metrikler

Ölçümün yarısı istemcide, yarısı sunucuda yapılır. Sadece k6 özetine bakan ekip neyin yavaşladığını görür ama nedenini göremez.

Ortalama süreye güvenmeyin. Ortalama 400 ms görünürken p95'in 3 saniye olması, her yirmi istekten birinin 3 saniye ya da daha uzun sürdüğü anlamına gelir. Kendi sunucunuzda yük altında top ve vmstat değerleri tırmanıyorsa, darboğazın steal, iowait ve load average değerleriyle hangi katmanda olduğunu ayırabilirsiniz.

Bulgulara göre iyileştirme ve tekrar test

Test bittiğinde elinizde bir sınır ve bir belirti olur. Yorumun ilk adımı, hatanın türüne bakmaktır. Belirli bir kullanıcı sayısından sonra aniden 503 ya da 508 dönmeye başladıysa bir sayı sınırına (PHP işçisi, eşzamanlı işlem, veritabanı bağlantısı) çarptınız. Süre yavaş yavaş uzayıp hata hiç çıkmıyorsa kaynak yavaşça tükeniyordur, genellikle işlemci ya da disk. 403 ve 429 yanıtları ise uygulamadan değil önündeki koruma katmanından gelir, kapasiteyle ilgisi yoktur.

Yavaşlık yalnız sepet ve ödeme adımlarındaysa, darboğaz çoğu zaman önbelleğe giremeyen isteklerin içindeki hesap ya da dış çağrıdır. WooCommerce sepet ve ödeme sayfasındaki yavaşlığın kaynağını istek bazında ölçmek, sunucu büyütmeden önce yapılacak iştir. Kampanya saatinde arka planda biriken stok senkronu ve e-posta gönderimi gibi işler de ödeme adımıyla yarışır. Bunların Action Scheduler kuyruğunda birikip birikmediğini test sırasında da izleyin.

Her düzeltmeden sonra aynı betiği, aynı basamaklarla ve aynı ortamda tekrar çalıştırın. Sonuçları tarih, değişiklik, en yüksek dengeli basamak, o basamaktaki p95 ve hata oranıyla bir tabloda tutun. Bir seferde tek değişiklik yapın, yoksa hangisinin işe yaradığını bilemezsiniz. Testten çıkan rakamlar disk ya da işlemci kıyaslaması değildir. Donanımın ham değerlerini ayrıca görmek isterseniz fio, sysbench ve iperf3 ile sunucu performans testi farklı bir soruya cevap verir.

Test kapasite sınırını gösteriyorsa

Uygulama tarafındaki kolay kazançları aldınız, test hâlâ hedefin altında bir yerde sınıra çarpıyor. Bu noktada karar veriye dayanır: hangi kaynak ilk tükeniyor ve hedef ile ulaşılan değer arasındaki fark ne kadar? E-ticaret sitesinin VDS'e ne zaman geçmesi gerektiğini gösteren sinyallerle test sonucunuzu yan yana koyun. Paylaşımlı paket yetmiyorsa Netx VDS paketlerinde vCore ve RAM size ayrılmış kaynaktır ve diskler NVMe'dir. Test hangi kaynağın eksik kaldığını gösterdiyse VDS Sihirbazı'nda vCore, RAM ve diski ayrı ayrı seçerek ihtiyacı o kaynağa göre kurabilirsiniz. Yeni sunucuda da aynı betiği çalıştırın. Geçişin gerçekten fark yarattığını ancak böyle görürsünüz.

Kendi kampanya hazırlığınız için mağaza tarafındaki kontrolleri WooCommerce hosting gereksinimleri yazısının kampanya bölümünde bulabilirsiniz.

Sık sorulan sorular

Test ne kadar sürmeli?

Her basamakta sistemin dengeye oturması için birkaç dakika gerekir. Kısa sıçramalar önbelleği ve bağlantı havuzlarını ısınmadan yakalar. Kampanyanız saatlerce sürecekse en yüksek basamağı en az 15–20 dakika tutan ayrı bir dayanıklılık turu da yapın. Bellek sızıntısı ve dolan disk gibi sorunlar ancak böyle görünür.

Bulut tabanlı yük testi servisleri kullanılabilir mi?

Kullanılabilir, kural aynıdır: yalnız kendi sisteminize ve sağlayıcınızı bilgilendirerek. Servisin yükü hangi bölgeden ürettiğine bakın. Türkiye dışından üretilen yük, ziyaretçinizin göreceğinden farklı bir gecikme ölçer. Kaynak IP aralıklarını önceden alıp sağlayıcınıza iletin.

Test trafiği analitik raporlarını bozar mı?

Protokol düzeyindeki araçlar JavaScript çalıştırmadığı için tarayıcı tabanlı analitik etiketleri çoğunlukla tetiklenmez. Sunucu günlüğüne dayalı raporlar ise bu trafiği sayar. Betikte tanımladığınız kullanıcı aracısı (user agent) adıyla bu satırları raporlardan ayıklayabilirsiniz.