WooCommerce Hosting: E-Ticaret Sitesi İçin Gerçek Gereksinimler

Bir tanıtım sitesi ile bir WooCommerce mağazası aynı yazılımı çalıştırıyor olabilir ama sunucuya bindirdikleri yük birbirinin yakınından geçmez. Tanıtım sitesinde sayfalar önbellekten sunulur, ziyaretçilerin çoğu aynı HTML’i görür. Mağazada ise sepet, ödeme ve hesap sayfaları kişiye özeldir; her istek PHP’yi çalıştırır ve veritabanına gider.

Bu fark, “hosting paketim yetiyordu, mağaza açınca site çöktü” tablosunun temel sebebi. Aşağıda WooCommerce’in sunucudan gerçekte ne istediğini, hangi kaynağın neden darboğaz olduğunu ve kampanya günü için nasıl gerçekçi bir hesap yapılacağını ele alıyoruz.

Neden paylaşımlı planlar bir noktadan sonra yetmiyor

Paylaşımlı hosting, “aynı anda az sayıda dinamik istek” varsayımı üzerine kurulu. WooCommerce bu varsayımı üç yerden bozar:

• Önbelleklenemeyen sayfalar. Sepet, ödeme, hesabım ve “sepete ekle” işlemlerinin önbelleğe alınması yasaktır; alınırsa bir müşteri diğerinin sepetini görür. Bu sayfalar her seferinde tam PHP çalıştırır.
• Admin-ajax ve arka plan görevleri. Sepet güncelleme, stok kontrolü, WooCommerce’in kendi Action Scheduler kuyruğu sürekli istek üretir.
• Ürün sorguları. Filtreli kategori sayfaları (renk, beden, fiyat aralığı) wp_postmeta tablosu üzerinde ağır JOIN’ler üretir. 5.000 ürünlü bir mağazada bu tablo rahatça 2-3 milyon satıra ulaşır.

Bu yüzden 30-50 ürünlük, günde 200 ziyaretçili bir mağaza iyi bir paylaşımlı pakette gayet iyi çalışırken; 3.000 ürünlü, kampanya yapan bir mağaza aynı pakette ödeme adımında 504 hatası vermeye başlar. Paylaşımlı ile VPS arasındaki eşiği paylaşımlı hosting ve VPS karşılaştırması yazısında ayrıntılandırdık.

PHP işçi sayısı: en çok gözden kaçan sınır

Disk ve trafik pazarlamada öne çıkar, ama mağazanın ayakta kalmasını belirleyen asıl rakam PHP worker sayısıdır. Worker, aynı anda işlenebilen PHP isteği sayısıdır. Basit bir örnek: 4 worker’ınız var ve bir ödeme isteği 800 ms sürüyorsa, teorik kapasiteniz saniyede 5 dinamik istektir. Altıncı istek kuyruğa girer; kuyruk dolarsa ziyaretçi 502/503 görür.

Sağlayıcınıza sorulacak net soru şudur: “Bu pakette eşzamanlı kaç PHP isteği çalıştırabiliyorum ve limit aşıldığında ne oluyor?” Cevap “sınırsız” ise gerçekte bir sınır vardır, sadece söylenmiyordur.

Veritabanı yükü ve object cache

WooCommerce sayfa başına 150-400 sorgu üretebilir. Burada iki büyük kazanç var:

1. Redis object cache. Tekrarlanan sorguların sonucunu bellekte tutar. Mağazalarda tipik olarak sorgu sayısını yarıdan fazla düşürür ve yönetim panelini belirgin şekilde hızlandırır. Paket açıklamasında Redis veya Memcached geçmiyorsa sorun.
2. HPOS (yüksek performanslı sipariş depolama). WooCommerce 8.2’den beri siparişleri wp_posts yerine kendi tablolarında tutabiliyor. Sipariş sayısı binleri geçen mağazalarda panel ve raporlar gözle görülür hızlanır. WooCommerce > Ayarlar > Gelişmiş > Özellikler ekranından açılır; geçmeden önce yedek alın ve eklenti uyumluluğunu kontrol edin.

Ayrıca wp_options tablosundaki otomatik yüklenen (autoload) veri miktarına bakın. 1 MB’ı geçen autoload verisi her sayfa isteğinde okunur; terk edilmiş eklentilerin bıraktığı ayarlar burada birikir. Sunucu tarafında LiteSpeed gibi bir web sunucusu kullanmak da statik içerik dağıtımında fark yaratır.

Önbellek stratejisi: neyi hariç tutmalı

Mağazada önbellek kurmak “eklentiyi aç, bitti” işi değil. Hariç tutulacaklar:

• /sepet, /odeme, /hesabim ve varsa /siparis-alindi sayfaları.
• woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_ ile başlayan çerezleri taşıyan istekler.
• Giriş yapmış kullanıcılar ve yönetim paneli istekleri.
• AJAX ile güncellenen “mini sepet” alanı — statik sayfada bile bu bölüm dinamik kalmalı.

Ürün ve kategori sayfaları önbelleklenebilir; asıl kazanç da orada. Ziyaretçilerin yüzde 80-90’ı vitrin sayfalarında dolaşır, sadece küçük bir kısmı ödeme akışına girer. Vitrini önbellekten sunmak, worker’ları gerçekten gereken yere ayırmanızı sağlar.

SSL, ödeme ve sipariş e-postaları

Ödeme alan bir sitede HTTPS pazarlık konusu değil. Türkiye’deki sanal POS entegrasyonlarının çoğu 3D Secure yönlendirmesi için geçerli bir sertifika ve doğru yapılandırılmış geri dönüş adresi ister. Ücretsiz Let’s Encrypt sertifikası teknik olarak yeterlidir; bazı bankalar ya da kurumsal beklentiler için OV sertifika tercih edilebilir. SSL sertifikası seçenekleri arasındaki fark güvenlik seviyesinde değil, doğrulama derinliğindedir.

Sipariş e-postaları ayrı bir konu ve mağazalarda en sık yaşanan sessiz sorun budur. WordPress varsayılan olarak wp_mail() ile PHP üzerinden posta gönderir; bu iletiler sıklıkla spam klasörüne düşer ya da hiç ulaşmaz. Müşteri “siparişim onaylanmadı” diye arar. Çözüm:

• SMTP eklentisi kurup gönderimi gerçek bir posta hesabından yapın.
• Gönderici adresi alan adınızla aynı olsun (siparis@magazaniz.com), @gmail.com olmasın.
• SPF, DKIM ve DMARC kayıtlarını doğru kurun; ayrıntılar SPF, DKIM ve DMARC yazısında.
• Yoğun mağazalarda işlemsel e-posta servisleri (ayrı bir gönderim altyapısı) teslim oranını yükseltir.

Kampanya günü kapasitesi ve gerçekçi kaynak hesabı

Kasım indirimleri, Sevgililer Günü veya bir reklam kampanyası, normal trafiğin 5-10 katını birkaç saate sıkıştırır. Hazırlık listesi:

1. Kampanyadan 2 hafta önce yük testi yapın. Yavaşlamanın başladığı eşzamanlı kullanıcı sayısını öğrenin.
2. Geçici olarak paket yükseltin. Çoğu sağlayıcıda kaynak artırımı saatler içinde yapılır; kampanya sonrası geri dönebilirsiniz.
3. Gereksiz yükü kapatın. Kampanya günü stok senkronizasyonu, toplu e-posta, otomatik yedek ve muhasebe entegrasyonu görevlerini gece saatlerine alın.
4. Statik dosyaları CDN’e verin. Ürün görselleri worker harcamadan dağıtılsın.
5. İzleyin. Kampanya boyunca sunucu yükünü ve hata kayıtlarını canlı takip edin; 502/504 hataları worker doygunluğunun ilk işaretidir.

Disk tarafında gerçekçi olun: ortalama 200 KB’lık optimize edilmiş bir ürün görselinden ürün başına 5 adet kullanıyorsanız, 3.000 ürün yaklaşık 3 GB yer kaplar. Sipariş ve kayıt verisi genelde çok daha küçüktür ama log tabloları hızla büyür. E-ticarete özgü kaynak planlamasını e-ticaret hosting gereksinimleri yazısında sayısal örneklerle ele aldık.

Özetle

• WooCommerce’te sepet, ödeme ve hesap sayfaları önbelleklenemez; bu sayfalar doğrudan PHP ve veritabanı yükü üretir.
• Paket seçerken disk ve trafiğe değil, PHP worker sayısına, RAM’e ve Redis desteğine bakın.
• Vitrin sayfalarını önbelleğe alıp WooCommerce çerezleri taşıyan istekleri hariç tutun.
• Sipariş e-postalarını SMTP üzerinden gönderin ve SPF/DKIM/DMARC kayıtlarını tamamlayın.
• Kampanya öncesi yük testi yapın, kaynağı geçici yükseltin, arka plan görevlerini yoğun saatlerden çıkarın.