WooCommerce Hosting’de Yüksek Trafiği Kaldırma Rehberi

WooCommerce trafiği arttığında sorun çoğu zaman tek bir yerden çıkmaz; sorgu süreleri, önbellek (cache) katmanı, CDN kullanımı, PHP-FPM/Apache-Nginx mimarisi ve veritabanı davranışı aynı anda etkiler. Bu rehberde amaç; “hosting yeter mi?” sorusunu soyut bırakıp, ölçülebilir hedefler koyarak WooCommerce mağazanızın yüksek trafik altında çökmeden, yavaşlamadan çalışmasını sağlamaktır. Plan; mevcut durumu teşhis etmek, darboğazı gidermek ve gerekirse ölçekleme stratejisi kurmaktır.

WooCommerce’te yüksek trafik neden “tek tıkla” çözülmez?

WooCommerce, tipik bir WordPress sitesine göre daha fazla dinamik iş yapar: alışveriş sepeti, ödeme akışı, fiyat/iskonto hesapları, stok doğrulama, kupon kontrolleri ve yoğun sorgular. Trafik yükseldiğinde aşağıdaki katmanlar sırayla zorlanır: - Uygulama katmanı (PHP): PHP worker sayısı, PHP-FPM havuzu (PHP-FPM) ve eş zamanlı isteklerde bekleme. - Web sunucusu (Nginx/Apache/LiteSpeed): bağlantı kuyruğu, keep-alive ayarları, dosya/geri dönüş süreleri. - Veritabanı (MySQL/MariaDB): WooCommerce sorguları, indeks eksikliği, yavaş replikasyon veya kilitlenmeler. - Önbellek katmanı (cache): sayfa cache, nesne cache (object cache), tarayıcı ve CDN cache. - Dosya depolama: SSD/NVMe, IOPS ve dosya sistemi performansı (özellikle yoğun log/medya).

Bu katmanların her birinde yanlış ayar “mükemmel hız”ı bozabilir. Bu yüzden doğru yaklaşım; önce ölçmek, sonra etkisini en fazla azaltan adımı seçmektir.

Net hedefler: Yüksek trafikte ölçülecek 6 metrik

Uygulama değişikliği yapmadan önce hedef metrikleri belirleyin. Aşağıdaki değerler, trafik artınca hangi katmanın sınırlandığını anlamanıza yardım eder:

Hedef metrik tablosu

Not: Hedef değerler mağazanızın boyutuna göre değişir. Kritik olan, aynı trafik senaryosunda “ölçüm + karşılaştırma” yapmanız.

Cache, CDN ve web sunucusu: Trafiği ilk yöneten katmanlar

Yüksek trafik altında en hızlı kazanım genellikle “dinamik iş yükünü azaltmak ve statik içeriği bölmek”tir. Aşağıdaki katmanlar bir arada çalışmalıdır.

1) Tarayıcı cache + sayfa cache (sayfa düzeyi)

WooCommerce’te her sayfa tamamen statik değildir; sepet/checkout gibi bölümler kullanıcıya özeldir. Bu yüzden ayar hedefi “tüm sayfayı cachelemek” değil, doğru sayfaları cache’lemektir.

• Ürün sayfaları, kategori sayfaları ve blog içerikleri: uzun süreli cache (ör. 1–24 saat)
• Home sayfası: trafik dönemi boyunca orta-uzun cache
• Sepet/checkout: kullanıcı bazlı, genelde cache’lenmez

Bu ayrımı düzgün yapmanın pratik sonucu şudur: PHP ve veritabanına giden istek sayısı düşer.

2) CDN (Content Delivery Network) kullanımı

CDN; resim, CSS, JS ve bazı HTML parçalarını coğrafi olarak yakına taşır. WooCommerce’te özellikle görsel yoğunluğu varsa CDN genelde TTFB/p95’i doğrudan iyileştirir.

CDN seçerken teknik ölçüt: - Cache hit oranı (yüksek olması beklenir) - Origin (kaynak sunucu) üzerindeki bant genişliği azalması - “Bypass” kurallarının doğru ayarlanması (checkout/sepet asla cache’de kalmamalı)

3) Nginx/Apache/LiteSpeed mimarisi ve PHP-FPM

Web sunucu tek başına çözüm değildir; fakat doğru mimari + doğru PHP havuzu kritik.

• PHP-FPM kullanıyorsanız pm.max_children ve worker sayısını, sunucu RAM’ine göre belirleyin.
• İstek patlamasında “process” yetersiz kalırsa HTTP 502/504 görülür; bu durumda uygulama değil kapasite sınırı vardır.

Nginx/Apache karşılaştırması (pratik karar rehberi)

Veritabanını “trafik kuyruğu” olmaktan çıkarın

Yüksek trafik geldiğinde veritabanı kilitlenirse, önbellek ne kadar iyi olursa olsun dynamic istekler yavaşlar. WooCommerce’te özellikle şu konular izlenmelidir: - Yavaş sorgular (ör. product meta, stok sorguları) - İndeks eksikliği - Uzun transaction/lock süreleri - Tema/eklentilerde gereksiz sorgu tekrarları

H3: MySQL/MariaDB tarafında kontrol listesi

• Slow query log açık mı?
• En sık görülen 10 sorgu hangileri? Ortalama değil p95/p99 önemli.
• Transaction süresi ve lock sayısı artıyor mu?
• Sunucu “tek diskte” hem veri hem temp kullanıyor mu? Disk IO wait yükseliyor mu?

Önerilen aksiyon sırası: 1) Slow query log’dan 10 sorguyu seçin. 2) Eklenti/tema sorgu davranışını düzeltin veya indeks ekleyin. 3) Cache/nesne cache ile tekrar sorguyu azaltın.

Nesne cache (Object Cache) ve session yönetimi

WooCommerce ve WordPress’te aynı veri tekrar tekrar okunur. Object cache kullanımı, dinamik isteklerin veritabanına bağımlılığını düşürür.

H3: Nesne cache için beklenen kazanç

• wp_options ve meta okumalarında azalma
• Aynı sayfa tekrar talebinde sorgu sayısının düşmesi
• p95 yanıt süresinde gözle görülür iyileşme

Object cache kurulumunda izlenecek teknik noktalar: - Redis/Memcached performansı ve bağlantı sayısı - Cache eviction (silme) ayarları - Suistimal olmasın diye doğru TTL kullanımı

Ölçekleme stratejisi: Tek sunucu mu, katman mı?

Yüksek trafikte “tek sunucu her şeyi yapar” yaklaşımı çoğu zaman maliyetli ve risklidir. Net yaklaşım; katmanlı ölçekleme ve kapasite sınırlarını planlamaktır.

H3: Ne zaman ölçekleme düşünmelisiniz?

Aşağıdaki sinyaller, mevcut altyapının kapasite sınırına yaklaştığını gösterir: - PHP worker sayısı dolduğu için artan 502/504 - p99 yanıt süresinde belirgin artış (özellikle kuyruk gibi) - Veritabanında lock artışı - CPU sürekli %80+ bandında ve yanıt süreleri düşmüyor

VDS/VPS/Dedicated seçiminde trafikleri sınıflandırın

NetKıyas’ta karşılaştırma yaparken sadece RAM/CPU değil; IOPS/SSD tipi, desteklenen cache mimarisi ve sunucu lokasyonu gibi faktörleri de aynı tabloda ele alın.

Yüksek trafik testini doğru yapın (tek deneme ile karar vermeyin)

“Canlıda deneyeyim” yaklaşımı WooCommerce için risklidir. Doğru test, aynı senaryoyu tekrarlayarak p95/p99 değişimini görmektir.

H3: Load testi için minimum senaryo seti

Aşağıdaki senaryoları sıralı test edin: - Ürün sayfası (kategoriden giriş) - Sepete ekleme (add to cart) - Checkout sayfası (form görünümü + alan yüklemeleri) - Ödeme sayfası (uygulama tarafı dahil) - Admin/özellikle stok/ürün güncelleme (düşük frekans)

Her testte en az şu çıktıları karşılaştırın: - p95/p99 yanıt süreleri - TTFB - hata oranı (4xx/5xx) - CPU/RAM grafikleri - veritabanı yavaş sorgu sayısı

Uygulama güvenliği ve hata toleransı: Çökmeden yönetim

Yüksek trafik yalnız performans değil hata yönetimi konusudur. - 5xx oranı artınca checkout akışınız bozulabilir. - Worker tükenmesi (PHP-FPM) olduğunda sistem kurtarma süresi uzar.

Net hata yönetimi kontrolleri

• Uygulama loglarında “memory exhausted”, “timeout”, “502/504” gibi kritik hatalar var mı?
• WAF/CDN rate-limit kuralları doğru mu? (Yanlış kural SEO/gerçek kullanıcı trafiğini de engeller.)
• Yedekleme (backup) planı var mı? Pik sırasında değişiklik yapıyorsanız rollback mekanizması gerekir.

Sunucu tarafında doğru kapasite planı (somut adımlar)

Trafik piklerinde “kapasite” genelde en son çare olur; ama zaman geldiğinde net karar gerekir.

H3: Kapasite planı için pratik formül

1) Mevcut tabloda p95 yanıt süresi ve hata oranını bulun. 2) Aynı senaryoyu %50–100 daha yüksek kullanıcı ile test edin. 3) p99 ve hata oranı hangi noktada bozuluyor belirleyin. 4) Bozulan noktayı güvenli aralığa taşıyacak şekilde: - PHP worker sayısını (pm.max_children) - veritabanı performansını (IOPS/indeks) - cache kapsamını (sayfa + nesne) - CDN kapsamasını güncelleyin.

Bu yaklaşım, “rastgele daha pahalı plan” yerine testle doğrulanmış yükseltme sağlar.

Sonuç: Şimdi neyi sırayla yapmalısınız?

WooCommerce’te yüksek trafiği kaldırmanın yolu, cache/CDN ile dinamik yükü azaltmak, veritabanını yavaş sorgu kaynaklı kilitlerden arındırmak ve PHP/web sunucusu kapasitesini testle doğrulamaktır. Bugün başlayacak en net aksiyon sırası şudur: mevcut ölçümleri alın (TTFB + p95/p99 + hata oranı), sayfa cache/CDN kurallarını doğru ayrım ile uygulayın, ardından slow query log’dan ilk 10 sorguyu hedefleyin. Bu adımlardan sonra da p99 hâlâ bozuluyorsa, kapasite ve ölçekleme tarafında (VDS/VPS/Dedicated) tespit ettiğiniz sınırı test ederek büyütün.

İsterseniz NetKıyas’ta sunucu karşılaştırması yaparken aynı trafik senaryosuna göre (cache var/yok, Redis var/yok, SSD/NVMe ve IOPS) filtre uygulayarak daha net bir seçim yapabilirsiniz.