k6, JMeter ve Locust ile Load Test ve Kapasite Ölçümü

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ın yanında altyapı kapasitesi de değerlendirilmelidir. Kritik soru şudur: Altyapı, beklenen trafiği kabul edilebilir yanıt süreleri ve hata oranlarıyla karşılayabilir mi? Load test, bu soruyu etkinlikten önce ölçümlerle değerlendirmeye yardımcı olur.

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?” sorusuna, test edilen ortam ve senaryo için ölçüme dayalı bir yanıt verir. Buna ek olarak, kaynak metrikleri ve loglarla birlikte değerlendirildiğinde hangi bileşenin önce tıkandığını (CPU, RAM, disk I/O, veritabanı, uygulama kodu, ağ) belirlemeye yardımcı olur.

Trafik patlamasından önce yapılan iyi planlanmış load testler, kapasite sorunlarını önceden saptayıp kesinti riskini azaltmaya yardımcı olabilir. Ö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 azaltmaya yardımcı olur. Bu rehberde, k6, Apache JMeter ve Locust için kurulum önkoşullarını, temel senaryo hazırlama ve çalıştırma adımlarını, sonuçları hosting kapasitesi açısından yorumlamayı ve ölçeklendirme kararlarını ele alacağız. İşletim sistemine özgü ayrıntılı araç kurulumu kapsam dışındadır; ilgili bölümlerde resmî kurulum kaynaklarına yönlendirme bulunur.

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: Yükü beklenen seviyenin ötesine kademeli artırarak sistemin kapasite sınırını, aşırı yükteki hata davranışını ve yük azaldığında nasıl toparlandığını gözlemlersiniz; amaç mutlaka sistemi çökertmek değildir.
• 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 birlikte kullanabilirsiniz. Örneğin bir e-ticaret kampanyasında önce load test ile hedef yükteki davranışı, ardından izin verilen kapsam ve durdurma eşikleri içinde stress ve spike testleriyle kapasite sınırlarını ve ani yük değişimlerine tepkiyi inceleyebilirsiniz. Kısa bir testin mutlaka sistemin kırılma noktasını göstereceğini varsaymayın.

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) çalışacak; kullanıcı başına hedef hız saniyede 1 istek olacak.” Bu hedef, yalnızca VU sayısıyla garanti edilmez; yanıt ve bekleme süreleri dikkate alınmalı, gerçekleşen RPS ayrıca ölçülmelidir.
• “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) 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 POST istekleri
• Ödeme, sipariş oluşturma gibi hem uygulama hem veritabanı için ağır olabilen 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

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 yazılım ve ayarları canlıya benzeyen, daha az kaynaklı bir kopyasını oluşturun (örneğin yarı kaynakla); kaynak farklarını kaydedin.
• Uygulamayı ve veritabanını buraya klonlayın (gerçek veriyi maskeleyerek). Ödeme akışlarını test ortamına veya taklit servislere yönlendirin; gerçek tahsilat, sipariş işleme ve e-posta/SMS gönderimini engelleyin. Üçüncü taraf servislere yük göndermek için ayrıca izin alın.
• Test yükünü ayrı bir makineden üretin ve yük üreten makinenin de kaynak kullanımını izleyin. Küçük ortamda gözlenen darboğazları değerlendirin; kapasiteyi varsayımsal bir katsayıyla üretime taşımayın. Üretim kapasitesi hedefini, mümkün olduğunca üretime eşdeğer kaynaklarda yeniden ölçerek doğrulayı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. Testten önce sağlayıcının yük testi kurallarına uygun izin ve kapsamı netleştirin; azami yükü, süreyi ve hata oranı/yanıt süresi için durdurma eşiklerini belirleyin. Test boyunca izlemeyi sürdürün ve eşikler aşıldığında yükü hemen kesebilecek bir sorumlu bulundurun. Canlıdaki ödeme ve sipariş denemelerinde de gerçek işlem ve bildirimleri engelleyin.

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 bile sağlayıcının kurallarına ve iznine bağlıdır. İzole bir kapasite testi ortamı gerekiyorsa VPS veya dedicated seçeneklerini değerlendirin; farklı bir ortamın sonucu mevcut paylaşımlı planın kapasitesini göstermez.
• VPS: Kaynakları ve yazılım ortamını yönetmek için esnek bir seçenek olabilir. CPU, RAM, disk ve ağ limitlerini, ayrıca kaynakların paylaşımlı mı ayrılmış mı olduğunu seçilen plan için doğrulayın; bunlar sonuçların yorumunu ve tekrarlanabilirliğini etkiler.
• Dedicated sunucu ve colocation: Sunucu kaynakları üzerinde daha fazla kontrol sağlayabilir; yüksek yük ve uzun süreli testler için değerlendirilebilir. Ancak ağ kapasitesi, ortak altyapı ve sağlayıcının test kuralları yine kapsamı sınırlar.

Load test sonuçlarınıza göre VPS kaynaklarını artırma ya da dedicated/colocation mimarisine geçiş gibi seçenekleri değerlendirebilirsiniz; uygulanabilirlik ve geçiş süresi seçilen hizmetin koşullarına bağlıdır. Ö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

Önkoşul: Yük üretecek makineye k6’yı kurun. Resmî Grafana k6 kurulum rehberindeki işletim sisteminize uygun yöntemi izleyin. Bağımsız arşivi kullanıyorsanız platformunuza uygun arşivi açıp k6 çalıştırılabilir dosyasını PATH’e ekleyin; aşağıdaki çalıştırma komutu bu hazırlığın tamamlandığını varsayar.

Aşağıdaki örnek, tek endpoint’i hedefleyen ve yükü artırma, sabit tutma ve azaltma aşamaları toplam 2 dakika olarak tanımlanmış basit bir k6 script’i. Bu bölümdeki örnekleri çalıştırmadan önce https://siteniz.com adresini, yük testi yapmaya yetkili olduğunuz hedef adresle değiştirin:

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

Ortalama, p95 ve p99 yanıt sürelerini, hata oranlarını ve RPS değerlerini birlikte değerlendirin; hedeflediğiniz yüzdeliklerin kullandığınız raporda yer aldığını doğrulayın. Hata oranının kapsamını da açıkça tanımlayın: yalnızca HTTP 5xx oranı, bağlantı hataları ve iş akışı doğrulama başarısızlıkları aynı ölçüm değildir. Aracın hata metriğini kabul kriterinizle eşleştirin; başarılı HTTP yanıtı tek başına işlemin doğru tamamlandığını göstermez. Bu sonuçları, DCHost üzerindeki sunucunuzdan izlediğiniz CPU/RAM/disk metrikleriyle birlikte yorumlayın.

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

Daha gerçekçi bir senaryoda, kullanıcıların birden fazla endpoint’i ziyaret etmesini modelleyebilirsiniz. Aşağıdaki örnekte her kullanıcı, her döngüde üç endpoint’i aynı sırayla birer kez çağırır; farklı ziyaret oranları modellenmez:

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ı.

Önkoşul: Test planını hazırlamadan önce JMeter’ı ve seçtiğiniz JMeter sürümünün desteklediği, güvenlik güncellemeleri sürdürülen bir Java çalışma ortamını kurun. Sürüm gereksinimleri ve kurulum adımları için resmî JMeter başlangıç rehberini izleyin. Aşağıdaki komut satırı örneği, jmeter başlatıcısının terminalden erişilebilir olduğunu varsayar. 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: Kapsamlarındaki her sampler çalışmadan önce o thread için bekleme uygular; farklı kullanıcıların arasına yerleştirilen bir bekleme değildir.
• Assertions: Yanıt içeriği, süre veya hata kodu gibi seçtiğiniz koşulların karşılanıp karşılanmadığını denetler.
• 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
• Bekletmek istediğiniz HTTP Request sampler’larının altına eklenen Uniform Random Timer’lar

tanımlayıp, 100 kullanıcıyı 2 dakikada kademeli artırarak 10 dakika boyunca koşabilirsiniz. Uniform Random Timer, belirlediğiniz sabit ofsete rastgele gecikme ekler. Bir timer’ı Thread Group seviyesinde bırakırsanız aynı kapsamdaki her sampler’dan önce uygulanır; aynı kapsamdaki birden fazla timer’ın tümü çalışır. Yalnızca bir isteği bekletmek için timer’ı o sampler’ın altına ekleyin.

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

JMeter GUI’sini test planını hazırlamak ve düşük yükte doğrulamak için kullanın; asıl yük testini komut satırından çalıştırın. Yük üretici makinede CPU, bellek, ağ ve Java heap kapasitesini test planına göre değerlendirin; hedeflenen kullanıcı sayısıyla birlikte gerçekten üretilen istek hızını da izleyin. Yük üreticinin sınırını hedef sunucunun kapasite sınırı olarak yorumlamayın. Test planınızı (.jmx dosyası) kaydettikten sonra aşağıdaki komutu kullanabilirsiniz. Komuttaki rapor/ çıktı dizini mevcut olmamalı veya boş olmalıdır; önceki raporu koruyup her çalıştırma için ayrı boş bir hedef seçin.

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ıyla zaman damgalarını eşleştirerek karşılaştırmak, hataların ne zaman arttığını ve olası nedenlerini araştırmanıza yardımcı olur.

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. Yerleşik HttpUser, HTTP/HTTPS içindir. Başka protokollerde kullanılan istemcinin gevent ile uyumlu I/O kullanması ve ölçümleri Locust’a bildirmesi gerekir; bloklayan uyumsuz bir istemci yük üretimini sınırlar.

Ş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 HTTP login/checkout akışları veya JWT token yenileme senaryoları modelleyecekseniz; WebSocket için uygun bir istemci/entegrasyon ve Locust istek olaylarına ölçüm bildirimi ayrıca gerekir
• Dağıtık (distributed) şekilde birden çok load generator’dan yük vermek istiyorsanız

Basit bir Locust örneği

Önkoşul: Yük üretici makineye seçtiğiniz Locust sürümünün desteklediği Python sürümünü kurun ve proje için ayrı bir sanal ortam oluşturup etkinleştirin. Resmî Locust kurulum rehberini izleyerek bu ortamda pip ile locust paketini kurun; locust -V ile kurulumun erişilebilir olduğunu doğrulayın. Aşağıdaki çalıştırma komutu bu ortamın etkin olduğunu varsayar.

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 kaydedin. Aşağıdaki komuttaki hedef adresi yük testi yapmaya yetkili olduğunuz adresle değiştirin. Başlatmadan önce web arayüzüne erişimi sınırlandırın: Locust varsayılan olarak tüm ağ arayüzlerinde dinler; yalnızca tarayıcıda localhost adresini kullanmak dış erişimi engellemez. Aşağıdaki komutu kullanacaksanız, 8089 portuna erişimi yalnızca güvenilir kaynaklara açan güvenlik duvarı kurallarını önceden doğrulayın. Alternatif olarak yerel adrese bağlama ve kontrollü tünel yaklaşımını resmî yapılandırma rehberine göre hazırlayın. Bu erişim önlemleri tamamlandıktan sonra komutu çalıştırın:

locust -H https://siteniz.com

Locust’u kendi bilgisayarınızda çalıştırıyorsanız 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 birden fazla yük üretici makineden eşzamanlı yük verebilirsiniz. Bu kullanım için seçilen altyapının kaynaklarını ve izin verilen trafik sınırlarını doğrulayın. Yük üreticilerde CPU kullanımını, Locust uyarılarını ve gerçekleşen RPS’yi izleyin; hedef yük üretilemiyorsa önce yük üretici sınırlarını ve senaryodaki beklemeleri inceleyin, bunu doğrudan hedef sunucunun kapasite sınırı saymayın.

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)?

Varsayımsal bir sonuç şöyle raporlanabilir: “Bu senaryo ve test süresinde saniyede 120 istek işlerken p95 700 ms, hata oranı %0,3, CPU %65, RAM %70 idi.” Bu, test edilen yük düzeyindeki performansı gösterir; tek başına maksimum kapasiteyi veya kaç gerçek kullanıcıya hizmet verilebileceğini kanıtlamaz. Kapasiteyi yorumlarken kullanıcı akışını, bekleme sürelerini, test süresini ve kabul kriterlerinin hangi yükte aşıldığını da belirtin.

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 motorunun I/O yükünü inceleyin; sorgu ve indeks düzenlemeleri ya da depolama kapasitesi değişikliği gerekebilir.
• 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 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 (ölçülen darboğaza göre VPS kaynaklarını artırma, 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, mevcut barındırma düzeninizi (paylaşımlı hosting, VPS, dedicated sunucu 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 düşük yükle başlayın. Sistem kararlıysa, örneğin hedef trafiğin %30–40’ına, ardından %60–70’ine ve %100’üne kademeli çıkın. Önceden belirlediğiniz hata, gecikme veya kaynak sınırları aşılırsa yükü artırmayın; testi durdurup nedeni inceleyin. 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

Sistem hedef yükü karşılıyor, yanıt süreleri ve hata oranları kabul sınırlarında kalıyor ve yeterli kaynak payı bulunuyorsa, test edilen senaryo ve yük için mevcut planla devam edebilirsiniz. Sınıra yakınsanız, şu seçenekleri masaya yatırma zamanı gelmiş demektir:

• Darboğaza göre daha fazla vCPU, RAM veya uygun disk kapasitesi ve I/O limitleri sunan bir VPS planına geçiş
• Yoğun veritabanı yükü için ayrı bir veritabanı sunucusuna geçiş
• Önüne Nginx reverse proxy ve yalnızca herkese aynı içeriği sunan sayfalar için tam sayfa cache ekleme; kişisel hesap, sepet ve ödeme yanıtlarını ortak cache dışında tutma
• CDN, tarayıcı cache ve object cache (Redis/Memcached) yapılarını güçlendirme

Bu adımları aldıktan sonra, aynı load test senaryosunu karşılaştırılabilir koşullarda tekrar koşup değişimin etkisini ölçün. Performans farkını ek maliyetle birlikte değerlendirerek yatırım kararını gözden geçirin.

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

Kampanya ve lansman gibi planlı etkinliklerde trafik artışına önceden hazırlanabilirsiniz; ancak artışın büyüklüğü ve zamanı her durumda öngörülemez. 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 rehberdeki k6, JMeter ve Locust örneklerini, test izniniz olan altyapıda gerçekçi senaryoları kontrollü yük altında ölçmek için başlangıç olarak kullanabilirsiniz.

Ö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.

Kampanya veya lansman öncesinde kapasite kararına ek olarak uygulama takvimini de belirleyin. VPS, dedicated sunucu veya colocation seçeneklerini değerlendirirken maliyet, yönetim sorumluluğu ve geçiş süresini karşılaştırın; değişikliklerden sonra yeniden test için zaman ayırın.