WooCommerce Kapasitesini Gerçek İş Yüküne Göre Planlamak
Bir kampanya sırasında ürün sayfaları hızlı kalırken sepet ve ödeme yavaşlayabilir. Bu, yalnız ziyaretçi sayısının kapasiteyi açıklamadığını gösterir: önbellek durumu, arama yoğunluğu, ödeme entegrasyonu ve arka plan işleri farklı kaynaklar tüketir. Kaynak artırmadan önce hangi isteğin nerede beklediğini ölçmek gerekir.
Bu yazıda, mağazanızın vCPU, RAM ve IOPS ihtiyacını nasıl gerçekçi ve basit bir yöntemle hesaplayabileceğimizi konuşacağız. Kuru bir formül listesi yerine, örneklerle ve akılda kalıcı günlük senaryolarla ilerleyeceğiz. Mesela kampanya dalgaları ne kadar etkiler, sepet ve ödeme adımlarının yükü diğer sayfalardan neden farklıdır, PHP süreçleri niye tıkanır, veritabanı ne zaman “yeter” der… Hepsini tek tek açacağız. Sonunda, elinizde pratik bir kontrol listesi ve karar verirken güvenebileceğiniz birkaç küçük formül olacak.
Ne Ölçüyoruz? Trafiği Hikâye Gibi Okumak
Trafiği ürün gezintisi, arama/filtreleme, sepet, ödeme ve arka plan işleri olarak ayırın. Aynı anda sitede bulunan 100 kişi, 100 PHP isteğinin aynı anda çalıştığı anlamına gelmez. Bir müşteri beklerken hiç istek göndermeyebilir; bir sayfa ise birden çok API isteği üretebilir. Kişiselleştirilmemiş, doğru önbellek kurallarıyla sunulan sayfalar kaynak sunucuyu daha az çalıştırır; her ürün sayfası otomatik olarak buna uygun değildir.
Kullanıcı sayısı, istek geliş hızı ve eşzamanlı çalışan istek sayısını ayırın. Doyuma ulaşmamış, dengeli bir akışta ortalama meşgul PHP işçisi yaklaşık olarak kaynağa ulaşan dinamik istek/saniye × ortalama işçi meşgul süresi ile tahmin edilir. Kuyrukta beklemeyi işçi servis süresine katmayın. Bu ortalama bir başlangıçtır; trafik dalgaları ve p95/p99 süreler için yük testi gerekir.
WooCommerce’de Yük Nerede Birikir?
Genelde dört cephede: arama ve filtreleme, varyasyonlu ürün detayları, sepet/kupon işlemleri ve ödeme adımı. Arama ve filtrelemede veritabanı yoğun çalışır. Varyasyonlu ürünlerde PHP’nin hesaplaması artar. Sepet ve kupon hareketlerinde oturum yazma/okuma devreye girer. Ödemede ise API çağrıları, veritabanı yazmaları ve çoğu zaman güvenlik kontrolleri üst üste gelir. Hikâyenin kilit karakterleri bunlar, yani bütçeyi onlar belirler.
vCPU Nasıl Planlanır? PHP İşçileri, Yan Yana Koşan Atletler
PHP-FPM’de bir işçi bir anda bir isteği işler; bunun tamamında CPU kullanmayabilir, veritabanı veya dış API bekleyebilir. Örneğin saniyede 15 dinamik istek ve istek başına ortalama 1 saniye işçi süresi yaklaşık 15 meşgul işçi demektir. Bu, 15 ziyaretçi veya 15 vCPU demek değildir. pm.max_children sınırını RAM, CPU, veritabanı bağlantıları ve kabul edilebilir kuyruk süresiyle birlikte belirleyin.
Sabit “işçi başına yarım çekirdek” oranı kullanmayın. CPU için başlangıç hesabı dinamik istek/saniye × istek başına CPU saniyesi ÷ hedef kullanım oranı olabilir; sonuç PHP için çekirdek eşdeğeridir. Örneğin 20 istek/s × 0,08 CPU saniyesi ÷ 0,70 yaklaşık 2,3 çekirdek eder. Bunlar varsayımsal sayılardır; aynı sunucudaki veritabanı ve işler ayrıca eklenir. Paylaşımlı vCPU kotası, işlemci nesli, throttling ve steal time nedeniyle sonuç gerçek plan üzerinde doğrulanmalıdır.
PHP-FPM, OPcache ve Hafifletilmiş Kod Yolu
İşçilerin hızlı koşması için yolu düzgün yapmak da gerekiyor. OPcache açık değilse, PHP dosyaları yeniden derlenir ve CPU boşuna yorulur. Gereksiz eklentiler birikir, her sayfada kullanılmayan özellikler yüklenir. Bu yüzden önce yol temizliği: gereksiz aktif eklentileri test ederek kaldırın, OPcache’i mantıklı boyutlarda açın, PHP-FPM’in havuz ayarlarını aşırı agresif tutmayın. Eğer bu adımlar ilginizi çekiyorsa, PHP-FPM, OPcache, Redis ve MySQL ayarlarını nerede, ne zaman, nasıl ayarlayacağına dair detaylı rehber tam yerinde bir kaynak.
Gerçekçi Test: Sahnenin Tozunu Yutmak
Üretime benzeyen izole test ortamında ürün, arama, sepet ve ödeme akışlarını kademeli yükle çalıştırın. Gerçek tahsilat, e-posta ve stok etkilerini test sağlayıcıları/verileriyle sınırlandırın. k6 gibi araçlarda istek hızını, kullanıcı düşünme sürelerini ve oturumları modelleyin. Kapalı kullanıcı modeli sistem yavaşladıkça gönderilen yükü azaltabilir; kampanya geliş hızını sınamak için uygun arrival-rate senaryosu seçin. CPU, FPM kuyruğu, DB kilitleri, disk, dış API süreleri ve hata oranlarını birlikte okuyun; uzun yanıt süresi tek başına işçi eksikliği kanıtı değildir.
RAM Nasıl Planlanır? Şefin Mutfağı, Tezgâhın Genişliği
RAM’i mutfaktaki tezgâh gibi düşünün: Bıçaklar, malzemeler, kaplar… Hepsi aynı anda yer ister. PHP süreçleri bir miktar bellek tüketir, veritabanı kendi payını alır, önbellekler yer kaplar, sistem dosya önbelleği de rahat bir alan ister. Tezgâh dar ise her şey üst üste gelir ve iş yavaşlar. Özellikle swap’e düşmek, mutfakta yerde kayıp düşmek gibi: kalkması zor ve yıpratıcı. Bu yüzden RAM planlaması, CPU’ya göre daha bağışlanmaz; eksikse bedelini hemen hissettirir.
RAM bütçesi için işçi başına ortalamadan çok ağır sepet/ödeme/rapor isteklerinin ölçülen bellek dağılımını kullanın. Azami işçi sayısı × işçi başına ihtiyatlı özel bellek + ortak OPcache + veritabanı + Redis + diğer işler + işletim sistemi ve pay başlangıç modelidir. RSS toplamı ortak sayfaları tekrar sayabilir; mümkünse PSS/özel bellek ve tüm havuzun gerçek kullanımıyla doğrulayın. PHP memory_limit, işçinin gerçek RSS ölçümü veya tüm sunucunun bellek sınırı değildir.
Niçin Bu Kadar Önemli?
WooCommerce’de oturumlar, sepet verileri ve ürün varyasyon hesapları RAM’e dokunur. Bir de arka planda çalışan e‑postalar, raporlar ve indekslemeler var. Bunlar küçük küçük atıştırır ama birikir. Çevik kalmak için, gereksiz eklentileri budayın, görüntü işleme görevlerini sıra dışı saatlere alın, arka plan işlerini parçalayıp zamanlayın. Yetersiz RAM, bu küçük işlerin domino taşı gibi birbirini devirmesine sebep olur.
IOPS ve Disk Verimi: Kasadaki Yazıcı Kaç Sayfa Basabiliyor?
Disk tarafını, kasadaki fiş yazıcısına benzetirim. Ne kadar hızlıysa, kuyruk o kadar çabuk erir. IOPS saniyede kaç okuma/yazma yapabildiğinizi anlatır. WooCommerce’de asıl kalın çizgiyi çizen, sepet ve ödeme anındaki yazmalardır. Sipariş kaydı, stok güncellemesi, kupon kullanımı, loglar, oturum ve geçici veriler… Her biri diske dokunur. Disk yavaşsa, her işlem bir sonrakini bekletir ve bu bekleyiş tüm katmanlara yayılır.
Sipariş/dakika talep tahminine yardımcı olur, fakat doğrudan IOPS sayısına çevrilemez. SQL sorguları disk önbelleği, grup commit, indeksler ve yazma birleştirmesi nedeniyle fiziksel I/O ile bire bir eşleşmez. Temsilî akışta IOPS yanında aktarım hızı, okuma/yazma oranı, blok boyutu, kuyruk derinliği ve özellikle senkron yazma gecikmesini ölçün. NVMe etiketi yerine planın gerçek disk kotası ve sürekli performansına bakın.
Ölçmek İçin Küçük Adımlar
Yük altında disk gecikmesi ve kuyruk derinliğini DB kilitleri, fsync beklemeleri ve sağlayıcı limitleriyle ilişkilendirin. Yüksek gecikme tek başına IOPS kotasının düşük olduğunu kanıtlamaz. Redis tabanlı kalıcı nesne önbelleği tekrarlanan okumaları azaltabilir; standart kurulum WooCommerce oturumlarının kalıcı kaydını otomatik olarak Redis’e taşımaz. Ayrı session backend’i kullanılacaksa dayanıklılık, eviction ve sepet doğruluğu ayrıca tasarlanmalıdır. Ağır rapor ve yedek işlerini RPO hedefini bozmadan zamanlayın.
Ağ, CDN ve Veritabanı: Gereksiz Trafiği Kapıdan Çevirmek
Statik dosyaları ve yalnız incelenmiş kişisiz HTML yanıtlarını CDN’de paylaşın. Sepet/ödeme/hesap yolları, eylem ve Store API çağrıları, oturum/yetki cookie’leri ve kişisel yanıtlar bypass edilmelidir. Ürün sayfaları üyelik fiyatı veya para birimiyle değişiyorsa doğru varyant veya bypass gerekir. WooCommerce CDN kuralları rehberi bu ayrımı ayrıntılandırır. Sıcak cache yanında boş cache, purge ve bypass yükünü de kapasite testine katın.
Veritabanında ise odak şu: gereksiz sorguları azaltmak, indeksleri doğru seçmek, tamponları mantıklı boyutlandırmak. Gereksiz hesaplamaları ve fiziksel okumaları azaltmak vCPU ve IOPS talebini düşürebilir; sorgu süresinin kısalması tek başına ikisinin de azaldığını göstermez. PHP tarafında tekrar tekrar yapılan aynı okumalara objekt önbelleğiyle set çekmek ve sipariş yazmalarını doğru bir işlem akışına bağlamak yararlı olabilir. Etkiyi sorgu süreleri, CPU tüketimi ve fiziksel I/O ölçümleriyle doğrulayın.
Kampanya Günü Stratejisi: Önceden Isıt, Akışı Basitleştir
Kampanyadan önce üretime benzeyen akışla prova yapın; sıcak, boş ve yenilenen cache durumlarını ölçün. Yalnız güvenli anonim sayfaları kontrollü hızla ısıtın. Görsel işleme ve indekslemeyi mümkünse daha sakin pencereye taşıyın. FPM işçi sayısını otomatik artırmak yerine, kuyruk nedeni, CPU/RAM payı ve veritabanı kapasitesi uygunsa kademeli değiştirip tekrar ölçün.
Ödeme eklentilerini kampanya sırasında gelişigüzel kapatmayın. Gereksiz işleri önceden belirleyip staging’de test edin; e-posta ve iş kuyruklarının yeniden deneme, gecikme ve çift işlem davranışını doğrulayın. Gereksiz debug gürültüsünü azaltırken hata, ödeme ve denetim kayıtlarını koruyun. Sürekli kaynak sınırına ulaşılıyorsa VPS’e kontrollü geçiş rehberi ile seçenekleri değerlendirin.
İzleme, Yedek ve Güvenlik: Sessiz Kahramanlar
İstek türüne göre p95/p99 süre, hata ve tamamlanan sipariş sayısını; FPM kuyruk/aktif işçilerini ve DB kilitlerini birlikte izleyin. RAM’de available memory, aktif swap-in/out, OOM ve cache evictions önemlidir; swap’te eski sayfaların bulunması tek başına anlık yetersizlik değildir. CPU throttling/steal, disk gecikmesi ve ödeme API beklemeleri hangi kaynağın sınıra geldiğini ayırmaya yardımcı olur.
Kapasite konuşurken yedekten bahsetmemek olmaz. Ölçüm ve deneme yaparken, veriyi güvende tutmak şart. Bunun için 3‑2‑1 yedekleme stratejisini pratik şekilde kurmak harika bir başlangıç. Güvenlik tarafında ise basit ilkelere sadık kalın: en az yetki, düzenli güncelleme ve görünür izleme. Tema ve eklentiler güncel değilse performans konuşmak çoğu zaman beyhude. Ayrıntıları toparlamak için VPS sunucu güvenliğini pratik ve ölçeklenebilir şekilde ele almak yazısı güzel bir tamamlayıcı olur.
Hızlı Hesap Şablonları: Defterin Kenarına Yazmalık
Varsayımsal bir hesapta kaynak PHP’ye 20 dinamik istek/s ulaşıyor ve işçi süresi ortalama 0,5 saniye olsun: ortalama 10 işçi meşguldür. CPU süresi 0,08 saniye/istek ise PHP talebi 1,6 çekirdek eşdeğeridir; %70 hedef kullanımda yaklaşık 2,3 çekirdek gerekir. Veritabanı ve diğer işler bu hesaba dahil değildir. Ortalama eşzamanlılığa eşit max_children koymak dalgaları karşılamayabilir; p95/p99, kuyruk ve bağımlılık sınırlarıyla yük testi yapın.
Aynı varsayımsal ortamda 16 işçi ve işçi başına 150 MiB özel bellek ölçülmüşse PHP işçileri yaklaşık 2.400 MiB yer ister. Ortak OPcache, veritabanının buffer pool’u ve bunun dışındaki bağlantı/buffer belleği, Redis’in veri belleği ve ek yükü, diğer işler ve işletim sistemi ayrıca bütçelenir. Bu sayılar paket önerisi değildir. Ağır istekler ve arka plan işleri dahil gerçek toplamı ölçün; tüm boş belleği cache’e ayırmayın.
IOPS bütçesini aynı senaryonun disk ölçümlerinden çıkarın. Örneğin arama ağırlıklı ve ödeme ağırlıklı iki testte IOPS/MB/s, senkron yazma gecikmesi ve p95 sipariş süresini karşılaştırın. Sorgu planı veya kilit beklemesi sorunu varsa daha hızlı disk tek başına çözmeyebilir. Redis cache isabetlerini ölçün; yetkili session/sipariş verilerini kaybedilebilir cache gibi ele almayın.
Kaynak Seçerken Resmî Notlar ve Yol Arkadaşları
Planı yaparken, platformun önerilerine göz atmak faydalıdır. WooCommerce dokümantasyonunda temel gereksinimler ve öneriler net şekilde listeleniyor. İhtiyacınız olan alt sınırları görmek ve sürüm uyumluluklarını takip etmek için WooCommerce’in sunucu gereksinimleri sayfasına kısa bir tur atın. Standartları bilmek, özel durumlarınızı değerlendirirken sağlam bir zemin sunar.
Kapanış: Sakin Hesap, Güçlü Akış
Toparlayalım. Kapasite planlama, vitrindeki sayılardan çok, perde arkasındaki akışı anlamakla ilgili. vCPU, RAM ve IOPS’i ayrı ayrı değil, bir orkestranın parçaları gibi düşünün. Dinamik istek hızını, istek başına CPU ve işçi meşgul sürelerini, bellek kullanımını ve disk beklemelerini bilirseniz, kaynak seçimi göze korkutucu görünmez. Küçük testlerle akışı prova edin, önbelleği akıllı kullanın, yoğun işleri yoğun olmayan saatlere taşıyın.
Pratik bir öneriyle bitireyim: Önce iş akışını sadeleştirin, sonra kaynakları büyütün. Bu sırayla gittiğinizde, yükseltmeler daha az ve daha etkili olur. Umarım bu rehber, mağazanızın bir sonraki kampanyasında size sakin bir nefes ve sağlam bir plan verir. Takıldığınız bir yerde, aklım her zaman şu cümlede: “Önce akış, sonra kaynak.” Bir dahaki yazıda görüşmek üzere…
