Bahis Sitesi Yük Testi: Büyük Etkinlik Öncesi Hazırlık

Büyük bir final, derbi ya da turnuva akşamı, bahis sitesinin normal günlerde hiç karşılaşmadığı bir yükle karşılaşmasına yol açabilir. Trafik kısa sürede ve aynı akışlara yığılır: giriş, canlı bahis ekranı, kupon ve para yatırma. Bu yükü önceden kontrollü biçimde simüle etmek, zayıf noktaları oyuncular bulmadan önce bulmanın yoludur. Bu rehberde yük testinin türlerini, araçlarını, senaryo tasarımını ve etkinlik günü planını anlatıyoruz.

Başlamadan önce: izin ve ortam

Yük testi, kendi sahip olduğun ya da açıkça test izni aldığın sistemlerde yapılır. Beyaz etiket ya da turnkey bir altyapı kullanıyorsan platformun önemli bir kısmı sağlayıcıya aittir; izinsiz yük testi hem sözleşmeye aykırı olabilir hem de DDoS koruma sistemlerini tetikleyerek aynı altyapıdaki başka siteleri etkileyebilir. Testi sağlayıcınla koordine et, mümkünse üretime benzeyen ayrı bir ortam kullan ve CDN ile güvenlik duvarı ekiplerini önceden bilgilendir.

Test türleri

• Yük testi: Beklenen zirve trafiğini belirli bir süre boyunca uygular. Soru şudur: sistem beklenen yükü hedeflenen yanıt süreleriyle taşıyabiliyor mu?
• Stres testi: Yükü kademeli olarak artırarak sistemin nerede ve nasıl kırıldığını bulur.
• Ani artış (spike) testi: Maç başlangıcı ya da gol anı gibi birkaç saniyelik sıçramaları taklit eder.
• Dayanıklılık (soak) testi: Orta seviyede yükü saatlerce sürdürerek bellek sızıntısı ve kaynak tükenmesi gibi yavaş gelişen sorunları ortaya çıkarır.

Araçlar

• k6: Senaryoların JavaScript ile yazıldığı, komut satırından çalışan modern bir araç. Eşik tanımları ve Grafana entegrasyonuyla öne çıkar.
• Locust: Python tabanlıdır, dağıtık çalışmaya uygundur ve karmaşık kullanıcı davranışlarını kod olarak modellemeyi kolaylaştırır.
• Apache JMeter: Uzun süredir kullanılan, arayüzlü bir araç. Ekibin JMeter deneyimi varsa mantıklı bir seçimdir.

Senaryo tasarımı

Gerçekçi bir test, tek bir sayfayı tekrar tekrar çağırmak değil, oyuncuların gerçek yolculuklarını taklit etmektir. Tipik bir büyük maç akşamı için şu akışları modelle:

1. Ana sayfa ve giriş: maç öncesinde yoğunlaşan oturum açma trafiği.
2. Canlı bahis ekranı: açık kalan bağlantılar ve sık oran güncellemeleri.
3. Kupon oluşturma ve onay: kritik anlarda yığılan yazma işlemleri.
4. Para yatırma: ödeme entegrasyonlarının yük altındaki davranışı.
5. Maç sonu: sonuçlanan kuponlar ve artan çekim talepleri.

Her akışın toplam trafik içindeki payını kendi geçmiş verinden çıkar. Hedef yükü belirlerken geçmişteki en yoğun gününü baz al ve üzerine bir güvenlik payı ekle. Canlı bahisin hangi katmanlarının yük altında zorlandığını canlı bahis altyapısı yazımızda ayrıntılı anlattık.

Örnek k6 betiği

Aşağıdaki betik sanal kullanıcı sayısını kademeli artırır, ana sayfa ile bir canlı bahis sayfasını çağırır ve eşik aşılırsa testi başarısız sayar. Adresler ve eşik değerleri örnektir; kendi hedeflerine göre değiştir:

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

export const options = {
  stages: [
    { duration: "5m", target: 200 },  // ısınma
    { duration: "10m", target: 200 }, // sabit yük
    { duration: "2m", target: 600 },  // ani artış
    { duration: "5m", target: 0 },    // soğuma
  ],
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<800", "p(99)<1500"],
  },
};

const BASE = __ENV.BASE_URL; // örnek: https://test.ornek-alanadin.com

export default function () {
  const home = http.get(BASE + "/");
  check(home, { "ana sayfa 200": (r) => r.status === 200 });
  sleep(1);

  const live = http.get(BASE + "/live");
  check(live, { "canlı sayfa 200": (r) => r.status === 200 });
  sleep(2);
}

Betiği “k6 run -e BASE_URL=https://test.ornek-alanadin.com yuk.js” komutuyla çalıştırabilirsin. Canlı oranlar WebSocket üzerinden geliyorsa k6'nın WebSocket desteğiyle açık bağlantı sayısını ayrıca test etmen gerekir.

Sonuçları okumak

• p95 ve p99 yanıt süreleri: Ortalama, yavaş isteklerin etkisini gizler. Oyuncuların hissettiği şey kötü uçlardır.
• Hata oranı: 5xx yanıtlar ve zaman aşımları yükle birlikte artıyorsa sistem sınırına yaklaşıyordur.
• Veritabanı bağlantı havuzu: Havuz tükendiğinde istekler kuyrukta bekler ve yanıt süreleri birden sıçrar.
• Kaynak eğrileri: Bellek kullanımı yük düştükten sonra da azalmıyorsa bir sızıntı olabilir.
• Dış bağımlılıklar: Ödeme ve veri sağlayıcılarının kendi hız sınırları, darboğazı senin sisteminin dışına taşıyabilir.

Darboğaz çoğu zaman uygulama sunucusundan önce veritabanında ya da bir dış bağımlılıkta görünür. Önbellekleme ve statik içerik dağıtımı için CDN rehberimize de göz atabilirsin.

Etkinlik günü planı

1. Etkinlikten önceki günlerde yeni sürüm yayınlamayı dondur.
2. Nöbetçi kişileri ve sağlayıcı iletişim bilgilerini netleştir.
3. Etkinlik saatlerini kapsayan sık aralıklı bir site kontrolü görevi kur; LLCBullet görevleri en sık 5 dakikada bir çalışabilir. Zamanlama örnekleri için cron yazımıza bakabilirsin.
4. Erişilemeyen site bildirimlerinin doğru kişiye gittiğinden emin ol; gerekirse webhook ile kendi alarm sistemine aktar.
5. Etkinlik sonrasında çalıştırma geçmişindeki yanıt sürelerini yük testi sonuçlarıyla karşılaştır ve farkları not et.

LLCBullet'in site kontrolü dışarıdan erişilebilirliği ve yanıt süresini ölçer; sunucu içi metrikleri ya da oran gecikmesini ölçmez. Bu yüzden onu kendi uygulama metriklerinin tamamlayıcısı olarak düşün.

Testten sonra ne yapmalı?

1. Bulunan darboğazları etkilerine ve düzeltme maliyetlerine göre sırala.
2. Her düzeltmeden sonra aynı senaryoyu tekrar çalıştırıp farkı ölç.
3. Sonuçları sağlayıcınla paylaş; altyapı tarafındaki sınırlar ancak onların ekibiyle birlikte aşılabilir.
4. Hedef yükü ve eşikleri bir sonraki büyük etkinlik için güncelle.

Yük testi tek seferlik bir iş değil, her büyük etkinlik öncesinde tekrarlanan bir hazırlık rutinidir. Sonuçları düzenli sakladığında, sistemin zaman içinde nasıl değiştiğini de görürsün.

Sık yapılan hatalar

• Tek bir IP'den test etmek: Güvenlik duvarı ya da CDN trafiği engelleyebilir ve sonuçlar gerçeği yansıtmaz.
• Önbelleği unutmak: Hep aynı sayfayı çağıran bir test yalnızca önbelleği ölçer.
• Yalnızca okuma trafiği üretmek: Kupon ve ödeme gibi yazma işlemleri çoğu zaman asıl darboğazdır.
• Sonuçları arşivlememek: Bir sonraki büyük etkinlikte karşılaştırma yapabilmek için her testin sonuçlarını sakla.