Trafik Patlamasından Önce Load Test Yapmak: k6, JMeter ve Locust ile Kapasite Ölçme Rehberi

Load Test Nedir, Trafik Patlamasından Önce Neden Hayati?

Bir kampanya, TV yayını, influencer işbirliği veya yeni özellik lansmanı planlarken içerik, reklam ve tasarım tarafında saatlerce çalışıyoruz; fakat çoğu ekip, işin en kritik kısmını son ana bırakıyor: altyapının bu trafiği gerçekten kaldırıp kaldıramayacağını netleştirmek. İşte load test, tam da bu sorunun cevabını önceden görebilmemizi sağlayan teknik araç seti.

Load test, uygulamanızı ve hosting altyapınızı belirli bir eşzamanlı kullanıcı sayısı ve istek hacmi altında deneyerek, nerede sınıra geldiğinizi görmenizi sağlar. Yani “Bu kampanya sırasında saniyede 200 istek alsak, sayfa yanıt süreleri ve hata oranı ne olur?” sorusunun matematiksel cevabıdır. Buna ek olarak, hangi bileşenin önce tıkandığını (CPU, RAM, disk I/O, veritabanı, uygulama kodu, ağ) ortaya çıkarır.

DCHost olarak şunu net şekilde görüyoruz: Trafik patlamasından önce yapılan iyi planlanmış birkaç load test, sonradan yaşanacak kesintilerin çok büyük kısmını engelliyor. Özellikle e-ticaret, SaaS, eğitim platformları ve haber sitelerinde, önceden ölçülmüş ve dokümante edilmiş kapasite değerleri, hem teknik ekiplerin hem de iş birimlerinin riskini azaltıyor. Bu rehberde, k6, Apache JMeter ve Locust ile pratik şekilde load test nasıl kurulur, sonuçlar hosting kapasitesi açısından nasıl yorumlanır ve DCHost altyapısında bu verilerle nasıl ölçeklenir, adım adım ele alacağız.

Load, Stress, Soak ve Spike Test: Kavramları Netleştirelim

Önce terminolojiyi sadeleştirelim; çünkü doğru türde test seçmeden sağlıklı kapasite kararı veremezsiniz.

• Load test: Belirli bir “beklenen” yük altında (örneğin 500 eşzamanlı kullanıcı, saniyede 100 istek) sistemin davranışını ölçersiniz. Bu rehberin odak noktası bu.
• Stress test: Bilinçli olarak kapasitenin çok üstüne çıkıp sistemin nerede çöktüğünü, nasıl toparlandığını ve hata verdiğinde ne yaptığını gözlemlersiniz.
• Soak (dayanıklılık) test: Orta-yüksek bir yükü saatlerce ya da günlerce verip bellek sızıntısı, bağlantı birikmesi, log şişmesi gibi zamanla ortaya çıkan sorunları yakalarsınız.
• Spike test: Kısa sürede aniden çok yüksek trafiğe çıkıp tekrar düşerek, ani piklere sistemin nasıl tepki verdiğini ölçersiniz.

Planladığınız etkinliğe göre bu test türlerini kombine etmek en sağlıklısıdır. Örneğin bir e-ticaret kampanyasında önce load test ile “hedef konfor bölgenizi”, ardından kısa bir stress + spike testiyle de “kırılma noktanızı” görmek iyi bir pratik.

Load Test Öncesi Hazırlık: Hedefler, Metrikler ve Senaryolar

İş hedeflerini teknik hedeflere çevirmek

Load testin başarısı, senaryoyu ne kadar gerçekçi tanımladığınızla doğru orantılı. İlk adım, pazarlama ve ürün ekiplerinden sayılar istemek:

• Kampanya döneminde günlük toplam beklenen ziyaretçi sayısı nedir?
• Pik anlarda kaç eşzamanlı kullanıcı bekleniyor?
• Bu kullanıcıların yüzde kaçı sepete ürün ekleyecek, yüzde kaçı ödeme deneyecek, yüzde kaçı sadece içerik tüketecek?
• Kabul ettiğiniz maksimum ortalama yanıt süresi (ör. 1 saniye altında) ve maksimum hata oranı (ör. %1’in altında 5xx) nedir?

Bu cevapları, k6 / JMeter / Locust senaryolarına şu şekilde çevirirsiniz:

• “10 dakika boyunca 200 VU (virtual user), her kullanıcı saniyede 1 istek yapacak.”
• “Kullanıcıların %70’i sadece listeleme gezinecek, %20’si ürün detaya bakacak, %10’u ödeme girişimi yapacak.”
• “95. yüzdelik (p95) yanıt süresi 800 ms’yi, hata oranı %1’i aşarsa testi başarısız say.”

İzlenecek metrikler: Sadece RPS ve yanıt süresine bakmayın

Load test çıktısında gözünüz doğal olarak yanıt süreleri ve saniyedeki istek (RPS/QPS) metriklerine kayar; ama altyapı tarafında aynı anda şu metrikleri de mutlaka takip etmelisiniz:

• CPU kullanımı (ortalama ve çekirdek başı)
• RAM kullanımı, swap kullanımı
• Disk I/O (okuma/yazma IOPS ve latency)
• Ağ trafiği (giden-gelen Mbps, paket kaybı)
• Veritabanı metrikleri (sorgu sayısı, yavaş sorgu sayısı, lock kontention)
• Uygulama error log’ları (özellikle 5xx, exception’lar)

Bu noktada, daha önce anlattığımız VPS kaynak kullanımı izleme rehberinde paylaştığımız htop, iotop, Netdata ve Prometheus gibi araçlar load test sırasında da mükemmel iş çıkarıyor. Testi başlatmadan önce bu izleme araçlarını konfigüre etmeniz, sonradan yorum yapmayı çok kolaylaştırıyor.

Gerçekçi kullanıcı senaryoları oluşturmak

Başarılı bir load test, “tek endpoint’e abanmaktan” çok daha fazlasıdır. Gerçek kullanıcı davranışına yakın bir karışım tasarlamak gerekir:

• Ana sayfa, kategori, ürün listesi gibi yüksek trafikli GET istekleri
• Sepete ekleme, favori, giriş yapma gibi hafif POST istekleri
• Ödeme, sipariş oluşturma gibi hem uygulama hem veritabanı için ağır POST istekleri
• Arama istekleri, filtreleme gibi index kullanımı ve CPU tüketen sorgular

Ayrıca cache ve CDN davranışı da çok kritik. Daha önce detaylandırdığımız tarayıcı ve CDN önbellekleme stratejileri, load test kurgusunda da dikkate alınmalı. Eğer gerçek dünyada trafiğinizin büyük bölümü CDN’den cache’ten servis edilecekse, load testi direkt origin sunucuya mı, yoksa CDN arkasından mı yapacağınıza özellikle karar vermelisiniz.

Test Ortamı ve Hosting Kapasitesi: DCHost Tarafında Nelere Dikkat Etmeli?

Canlı mı staging mi? Gerçekçi ama kontrollü ortam

İdeal senaryo, canlıya mümkün olduğunca benzeyen bir staging ortamında load test yapmaktır. Ancak çoğu zaman maliyet ve zaman nedeniyle bire bir kopya kurulamıyor. O zaman şu yaklaşımı öneriyoruz:

• Canlıda kullanılan DCHost VPS ya da dedicated sunucunun aynı konfigürasyonda küçük ölçekli bir kopyasını oluşturun (örneğin yarı kaynakla).
• Uygulamayı ve veritabanını buraya klonlayın (gerçek veriyi maskeleyerek).
• Load testi burada çalıştırıp elde ettiğiniz kapasiteyi doğrusal olmayan ama yaklaşık bir katsayıyla üretim için yorumlayın.

Eğer staging kurma şansınız yoksa ve canlı ortamda test yapmak zorundaysanız, bunu düşük yoğunluklu saatlere kaydırmalı, iş birimlerini bilgilendirmeli ve mutlaka kademeli yük artırımı yapmalısınız.

Paylaşımlı hosting, VPS ve dedicated için yaklaşım farkları

• Paylaşımlı hosting: Aynı fiziksel kaynakları başka kullanıcılarla paylaştığınız için agresif load test genellikle önerilmez. Kısa ve düşük yoğunluklu testler yapılabilir, ama ciddi kapasiteleri ölçmek için VPS veya dedicated tercih etmelisiniz.
• VPS: Bugün çoğu orta-büyük proje için en esnek alan burası. CPU, RAM, disk ve ağ limitleri net olduğu için load test sonuçlarını kapasite planlamasına çevirmek daha kolaydır.
• Dedicated sunucu ve colocation: Tam kaynak kontrolü sağladığı için, yüksek trafikli projelerde hem load hem stress hem de soak testleri için idealdir.

DCHost altyapısında, load test sonuçlarınıza göre VPS ölçeklendirme ya da daha güçlü dedicated/colocation mimarisine geçiş gibi adımları oldukça hızlı planlayabiliyoruz. Özellikle WooCommerce, Magento, Laravel/Node.js gibi yoğun kaynak kullanan uygulamalarda önce küçük bir load test, sonra kampanya dönemleri için hosting ölçeklendirme rehberimizle birlikte kapasiteyi netleştirmek ciddi fark yaratıyor.

Çok katmanlı mimari ve load balancer etkisi

Eğer mimarinizde web sunucusu + uygulama sunucusu + veritabanı ayrımı ve belki bir de Nginx reverse proxy / basit load balancer katmanı varsa, her bir katmanın sınırını ayrı ayrı görmek istersiniz. Küçük projeler için yazdığımız Nginx reverse proxy ve basit load balancer rehberi, bu katmanı hızlıca ayağa kaldırmak için güzel bir başlangıç.

Load test sırasında, trafiği önce load balancer’a yönlendirip oradan arka uç sunucularına dağıtarak, tek noktada boğulma riskini de test etmiş olursunuz.

k6 ile Load Test: Modern, Script Tabanlı Yaklaşım

k6’yı ne zaman tercih etmeli?

k6, modern, geliştirici dostu ve özellikle CI/CD süreçlerine entegre etmek için çok uygun bir load test aracı. Senaryoları JavaScript ile yazdığınız için, frontend/backend ekipleri tarafından da kolayca okunup güncellenebiliyor. Özellikle:

• API performansını ölçmek
• Tekrar edilebilir, kodlanmış load test senaryoları oluşturmak
• Git tabanlı versiyon kontrol ve CI pipeline’larında otomatik performans testi koşmak

gibi durumlarda k6 oldukça güçlü.

Basit bir k6 senaryosu

Aşağıdaki örnek, tek endpoint’i hedefleyen ve 1 dakika boyunca kademeli yük veren basit bir k6 script’i:

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

export const options = {
  stages: [
    { duration: "30s", target: 50 },   // 30 saniyede 50 eşzamanlı kullanıcıya çık
    { duration: "1m", target: 50 },    // 1 dakika boyunca 50 kullanıcıyı koru
    { duration: "30s", target: 0 },    // 30 saniyede tekrar 0'a in
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"], // p95 800 ms altında olsun
    http_req_failed: ["rate<0.01"],   // hata oranı %1'in altında olsun
  },
};

export default function () {
  const res = http.get("https://siteniz.com/");
  sleep(1);
}

Bu script’i test.js olarak kaydedip şu komutla çalıştırabilirsiniz:

k6 run test.js

Çıktıda ortalama, p95, p99 yanıt sürelerini, hata oranlarını ve RPS değerlerini göreceksiniz. Bu sonuçları, DCHost üzerindeki sunucunuzdan izlediğiniz CPU/RAM/disk metrikleriyle birlikte yorumlamak kritik.

Gerçekçi k6 senaryoları: Birden fazla endpoint

Daha gerçekçi bir senaryoda, kullanıcıların farklı endpoint’lere farklı oranlarda gittiğini modelleyebilirsiniz:

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

export const options = {
  vus: 100,
  duration: "5m",
};

export default function () {
  http.get("https://siteniz.com/");        // ana sayfa
  sleep(0.5);
  http.get("https://siteniz.com/kategori"); // kategori
  sleep(0.5);
  http.get("https://siteniz.com/urun/123"); // ürün detay
  sleep(1);
}

Bu yapıyı fonksiyonlara bölerek, “sadece gezinen kullanıcı”, “sepet yapan kullanıcı”, “ödeme deneyen kullanıcı” gibi profil bazlı senaryolar da oluşturabilirsiniz.

Apache JMeter ile Load Test: GUI’den Komut Satırına

JMeter ne zaman faydalı?

Apache JMeter, uzun yıllardır kullanılan ve özellikle HTTP(S), SOAP/REST, veritabanı, FTP gibi çok çeşitli protokolleri destekleyen güçlü bir araç. En belirgin avantajı, GUI arayüzü ile senaryo tasarlamayı kolaylaştırması. Aşağıdaki durumlarda JMeter öne çıkar:

• Teknik olmayan ekiplerin de test planını okuyup yorumlamasını istiyorsanız
• Çok adımlı, form içeren, cookie/session yönetimi olan karmaşık akışları simüle edecekseniz
• Protokol çeşitliliği (ör. HTTP + JDBC + FTP) gerekiyor ise

Temel bileşenler: Thread Group, Sampler, Listener

JMeter’ın temel yapı taşlarını şöyle özetleyebiliriz:

• Thread Group: Kaç sanal kullanıcı (thread) olacağını, ne kadar sürede artacağını (ramp-up) ve kaç döngü çalışacağını belirler.
• HTTP Request Sampler: Test etmek istediğiniz gerçek HTTP isteklerini tanımladığınız bileşen.
• Timers, Assertions: Kullanıcılar arası bekleme süreleri ve yanıt süresi/hata kodu gibi kriterleri kontrol eden ekler.
• Listeners: Sonuçları grafik, tablo, log vb. formatlarda görmenizi sağlar (View Results Tree, Summary Report vb.).

Örnek bir senaryoda, bir Thread Group içinde:

• Ana sayfa için bir HTTP Request
• Kategori için bir HTTP Request
• Ürün detayı için bir HTTP Request
• Arada Uniform Random Timer’lar

tanımlayıp, 100 kullanıcıyı 2 dakikada kademeli artırarak 10 dakika boyunca koşabilirsiniz.

Performanslı kullanım için non-GUI mod

JMeter’ı büyük hacimli testlerde GUI ile çalıştırmak hem test makinesini yorabilir hem de sonuçları yanıltabilir. Bu yüzden test planınızı (.jmx dosyası) kaydedip, load generator makinenizde komut satırından şöyle çalıştırmanızı öneririz:

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

Buradaki -e -o rapor/ parametreleri, test sonunda HTML raporu da üretir. Bu raporu uygulama ve altyapı log’larınızla yan yana açtığınızda, hangi dakikada hangi hataların arttığını çok net görürsünüz.

Locust ile Load Test: Python ile Davranış Bazlı Senaryolar

Locust’un güçlü olduğu alanlar

Locust, Python tabanlı, özellikle davranış odaklı (behavior-driven) load test senaryoları yazmak için ideal bir araç. Kullanıcıların “günlük hayattaki davranışlarını” birer Python sınıfı ve fonksiyonu gibi modelleyebildiğiniz için, karmaşık iş akışlarını ifade etmek oldukça doğal hale geliyor.

Şu durumlarda Locust iyi bir tercih:

• Ekibiniz Python’a hâkimse ve testleri de kod gibi version control altında tutmak istiyorsanız
• Karmaşık login/checkout akışları, JWT token yenileme, websocket vb. senaryolar modelleyecekseniz
• Dağıtık (distributed) şekilde birden çok load generator’dan yük vermek istiyorsanız

Basit bir Locust örneği

Aşağıdaki örnek, ana sayfa ve ürün detayı endpoint’lerini farklı ağırlıklarla çağıran basit bir kullanıcı tanımıdır:

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)  # istekler arası 1-3 sn bekle

    @task(3)
    def index(self):
        self.client.get("/")

    @task(1)
    def product_page(self):
        self.client.get("/urun/123")

Bu dosyayı locustfile.py olarak kaydedip şu komutla çalıştırabilirsiniz:

locust -H https://siteniz.com

Daha sonra tarayıcıdan http://localhost:8089 arayüzüne girerek kullanıcı sayısı, artış hızı ve hedef host gibi parametreleri GUI üzerinden belirleyip testi başlatabilirsiniz. Büyük testlerde ise Locust’u distributed modda, birden fazla worker ile kullanarak DCHost üzerindeki load generator VPS’lerinizden eşzamanlı yük verebilirsiniz.

Sonuçları Yorumlamak: Bu Sunucu Kaç Kullanıcı Kaldırıyor?

Kabul kriterlerini en baştan tanımlayın

Testi çalıştırmadan önce, şu üç sorunun cevabını netleştirin:

• p95 ve p99 yanıt süresi hedefleriniz nedir (ör. p95 < 800 ms, p99 < 1500 ms)?
• Kabul edilebilir maksimum hata oranı nedir (örn. toplam isteklerin < %1’i 5xx olabilir)?
• Sunucu kaynaklarının maksimum ne kadarına çıkılabilir (örn. CPU ortalama < %75, RAM < %80)?

Test bitince, “Saniyede 120 istek aldığımızda p95 700 ms, hata oranı %0.3, CPU %65, RAM %70 idi.” gibi cümleler kurabiliyorsanız, işte o zaman gerçekten kapasiteyi ölçmüş olursunuz.

Darboğazı bulmak: CPU mu, I/O mu, veritabanı mı?

Load test çıktısı tek başına “nerenin tıkandığını” söylemez; onu altyapı izleme verileriyle birleştirmeniz gerekir. Örneğin:

• CPU %90+, load average çok yüksek, ama disk ve ağ normal: Muhtemelen PHP/Node.js uygulama kodu veya veritabanı sorguları ağır.
• Disk I/O ve IOPS tavan yapmış, iotop’ta mysqld veya elasticsearch öne çıkıyor: Veritabanı veya arama motoru tuning ve indeksleme ihtiyacı var.
• Network throughput limitlerine yaklaşılıyor, TCP bağlantı sayısı tavan yapıyor: Aynı anda çok fazla open connection, keep-alive ayarları veya proxy/Nginx tuning gerekebilir.

Özellikle MySQL/PostgreSQL tarafında, daha önce paylaştığımız WooCommerce kapasite planlama rehberi ve büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberi bu darboğazların giderilmesinde oldukça işe yarıyor.

Load test → Ayar değişikliği → Yeniden test döngüsü

Tek seferlik bir load test, çoğu zaman sadece fotoğraf çeker. Asıl değer, şu döngüyü birkaç kez tekrarladığınızda ortaya çıkar:

1. Mevcut mimari ve ayarlarla load test çalıştır.
2. Darboğazı tespit et (ör. CPU yüksek, veritabanı yavaş, PHP-FPM child sayısı yetersiz vb.).
3. İyileştirme yap (daha yüksek DCHost VPS planı, dedicated sunucuya geçiş, PHP-FPM/OPcache tuning, veritabanı indeksleri, CDN ve cache ayarları vb.).
4. Aynı senaryoyla load test’i tekrar çalıştır ve eski sonuçlarla kıyasla.

Bu yaklaşımı, daha önce ayrıntılı anlattığımız CPU, I/O ve MySQL darboğazı teşhis rehberi ile birleştirdiğinizde, yalnızca kapasiteyi değil, genel olarak performansı da ciddi şekilde iyileştirebilirsiniz.

DCHost ile Trafik Patlamasına Hazırlanmak: Pratik Yol Haritası

1. Mevcut durumu ve hedef trafiği netleştirin

Önce, DCHost üzerindeki mevcut hosting paketinizi (paylaşımlı, VPS, dedicated veya colocation) ve şu anki tipik trafik profilinizi çıkarın. Ardından pazarlama ekibinden kampanya ya da lansman için beklenen pik değerleri alın. Bu iki bilgiyi yan yana koyup “şu anki mimari bu hedefi kaldırabilir mi?” sorusunu soralım.

2. Basit bir k6/JMeter/Locust senaryosu hazırlayın

Bu rehberdeki örneklerden yola çıkarak, sitenizin ana akışını (listeleme + detay + kritik işlem) temsil eden bir senaryo yazın. İlk testiniz mükemmel olmak zorunda değil. Önemli olan, ölçmeye başlamak ve tekrar edilebilir bir script elde etmek.

3. İzleme ve loglamayı devreye alın

Load testten önce, VPS/dedicated sunucunuzda temel izleme araçlarını ve loglamayı mutlaka kontrol edin. Bu konuya özel olarak hazırladığımız VPS izleme ve alarm kurulum rehberimiz, Prometheus + Grafana + Uptime Kuma ile çok pratik bir başlangıç sunuyor. Test sırasında bu dashboard’ları açık tutarak, sistemin verdiği tepkiyi anlık olarak izleyebilirsiniz.

4. Testi kademeli artırın, sonra sonuçları soğukkanlı okuyun

İlk denemede hedef trafiğin %30–40’ı kadar yük verin, ardından %60–70’e, sonra %100’e çıkın. Her aşamada:

• Yanıt süreleri ve hata oranlarını
• CPU/RAM/disk/i/o ve veritabanı metriklerini
• Uygulama ve web sunucusu loglarını

karşılaştırın. Özellikle HTTP 5xx, connection timeout, database lock, PHP fatal error gibi sinyalleri yakalamaya çalışın.

5. Kapasite ve ölçeklendirme kararını verin

Test sonuçları hedeflerin altındaysa, yani sistem rahatça kaldırıyorsa, mevcut planla devam edebilirsiniz. Sınıra yakınsanız, şu seçenekleri masaya yatırma zamanı gelmiş demektir:

• DCHost VPS planını bir üst seviyeye çıkarma (daha çok vCPU, RAM, NVMe disk)
• Yoğun veritabanı yükü için ayrı bir veritabanı sunucusuna geçiş
• Önüne Nginx reverse proxy ve tam sayfa cache ekleme
• CDN, tarayıcı cache ve object cache (Redis/Memcached) yapılarını güçlendirme

Bu adımları aldıktan sonra, aynı load test senaryosunu tekrar koşup kazanımı ölçmek, yatırımın geri dönüşünü netleştirmenizi sağlar.

Özet ve Son Söz: Trafik Patlaması Sürpriz Olmasın

Trafik patlamaları çoğu zaman “sürpriz” gibi yaşansa da aslında büyük ölçüde öngörülebilir olaylar. Bir kampanya takvimi, lansman planı veya içerik stratejisi hazırlandığı anda, teknik tarafta da eş zamanlı olarak load test planı yapılması gerekiyor. Bu rehberde gördüğünüz gibi, k6, JMeter ve Locust ile gerçekçi senaryolar oluşturup DCHost üzerindeki hosting altyapınızı zorlamak, sanıldığı kadar karmaşık değil.

Önemli olan, işe önce hedefleri tanımlayarak başlamak: Kaç kullanıcı, hangi akışları, hangi yanıt süresi ve hata oranlarıyla deneyimlemeli? Ardından, uygun araçla senaryoyu kodlamak, test boyunca sistem metriklerini izlemek ve çıkan sonuçlara göre ölçeklendirme, optimizasyon ve mimari iyileştirme adımlarını planlamak. Tek seferlik bir “deneme atışı” değil, döngüsel bir iyileştirme süreci olarak ele aldığınızda, altyapınız her testle birlikte biraz daha olgunlaşıyor.

Eğer elinizde bir kampanya ya da lansman takvimi varsa ve “Bu trafiği kaldırır mıyız?” sorusu kafanızı kurcalıyorsa, DCHost ekibi olarak birlikte senaryo tasarlamaktan, load test araçlarını kurmaktan ve sonuçları yorumlamaktan memnuniyet duyarız. Projenizin ölçeğine uygun VPS, dedicated sunucu veya colocation seçenekleriyle, trafik patlamasını risk değil, fırsata çevirmenize yardımcı olabiliriz.