WooCommerce Kapasite Planlama Rehberi: vCPU, RAM, IOPS Nasıl Hesaplanır?

Tüm Olanlar Bir Öğlen Molasında Başladı: Gerçek Bir WooCommerce Hikâyesi

Hiç başınıza geldi mi? Sessiz sakin bir öğlen, kahvenizi almışsınız, mağazanızda yeni ürünü yayına almışsınız. Derken sosyal medyada paylaşılan bir hikâye patlıyor ve dakikalar içinde sitede bir kalabalık… Sayfalar biraz ağır, sepet bazen takılıyor, ödeme ekranında bekleme dönüyor. Tam o anda aklınızdan geçen tek cümle şu oluyor: “Keşke kapasiteyi bir tık daha yüksek planlasaydım.” Benzerini yaşadığım bir günde, tam da o an, kapasite planlamanın sadece bir sayı işi olmadığını fark ettim. O gün bugündür, bu konuyu hem teknik hem de günlük hayata dokunan bir dille anlatmayı seviyorum.

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

Bir e‑ticaret mağazasında trafik, sadece ziyaretçi sayısıyla açıklanmaz. Asıl mesele, aynı anda içeride kaç kişinin “gerçek iş” yaptığıdır. Ürün arayan, filtreleyen, sepetine ekleyip çıkaran ve ödeme butonuna basan kullanıcıların her biri sunucuda farklı yoğunluk oluşturur. Mesela şöyle düşünün: 100 kişi ana sayfada geziniyor diyelim, ama aynı anda 12 kişi sepette ve 4 kişi de ödeme adımında. Asıl kaynak ihtiyacını belirleyen, bu küçük ama ağır gruplardır. Geri kalanı çoğunlukla önbellekten servis edilebilir; kritik olan, yoğun ve dinamik isteklerin ritmidir.

Bu yüzden kapasite planlamada “eşzamanlılık” kavramını kullanırız. Eşzamanlı kullanıcı sayısı, belirli bir anda aktif işlem yapan kişileri anlatır. Bir arama, bir ürün varyasyonunu seçmek, sepeti güncellemek veya ödeme formunu göndermek… Her biri, sunucunun düşünmesini gerektiren anlar. Bu anları sayabildiğinizde ve ne kadar sürdüğünü gördüğünüzde, CPU ve RAM tahmini neredeyse kendiliğinden netleşir. İyi haber şu: Bunu yapmak için karmaşık bir matematiğe gerek yok; birkaç basit ölçüm ve gözlem yeterlidir.

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

vCPU’yu, aynı anda koşan atletler gibi düşünün: Her PHP işçisi (worker), bir kullanıcı isteğini koşuyor. Koşucu sayısı azsa kuyruğa girer, çoksa pist kalabalıklaşır ve düzensizlik artar. Burada amacımız, aynı anda aktif olacak kadar işçi ayarlamak ama pistte nefes payı bırakmak. Peki bu sayı nasıl bulunur? Basit: Eşzamanlı dinamik istek sayınızı ve ortalama yanıt sürenizi tahmin edin. Bir istek yaklaşık bir saniye sürüyorsa ve aynı anda ortalama 15 ağır istek geliyorsa, en az 15 aktif işçi isteyeceksiniz. İşçilerin arkasında da onlara nefes verecek vCPU kaynağı olmalı.

PHP işçileri vCPU ile kol kola yürür. Her işçi toplu halde CPU’ya yüklenmez; bazen IO bekler, bazen hızlıca biter. Yine de pratikte, yoğun anlarda işçi başına yarım çekirdek civarı bir bütçe ayırmak çoğu senaryoda nefes aldırır. Çok karmaşık eklentiler veya raporlar varsa, bu payın arttığını görürsünüz. Benim yaklaşımım şu: Önce beklediğim eşzamanlı ağır istek sayısını belirliyorum, sonra bu sayıyı CPU bütçesine çevirip üstüne yüzde yirmi kadar esneklik koyuyorum. Bu küçük pay, kampanya anlarında hayat kurtarıyor.

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, her istemde aynı dosyalar yeniden yorumlanır ve CPU boşuna yorulur. Gereksiz eklentiler birikir, her sayfada kullanılmayan özellikler yüklenir. Bu yüzden önce yol temizliği: aktif olmayan eklentileri kapatı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

Plan yaparken, bir de sahaya inmek şart. Hafif bir yük testi ile siteyi küçük dalgalar halinde yoklayın. Ziyaret akışını benzeten bir senaryoda ürün listeleme, ürün detay, sepet ve ödeme uçlarını dönüşümlü koşturun. Hızla kararan göstergeleri göreceksiniz: CPU tavan yapıyorsa vCPU yetmiyor, yanıt süreleri uzuyorsa işçi sayısı az, hata oranları artıyorsa bir yerlerde dar boğaz var. Böyle testleri kolaylaştıran araçlardan biri k6 ile yük testi senaryosu yazmak; kısa scriptlerle gerçek akışları taklit etmek mümkün. Küçük turlarla başlayın, yavaş yavaş tempoyu artırın.

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.

Pratik yaklaşım şöyle: Üretimde beklediğiniz maksimum PHP işçi sayısı ile işçi başına ortalama bellek tüketimini çarpın. Buna veritabanının buffer/paylaşım ihtiyacını ekleyin. Redis gibi önbellek kullanıyorsanız makul bir üst sınır belirleyin. Son olarak, sistemin dosya önbelleği ve nefes payı için anlamlı bir boşluk bırakın. Bu toplam, RAM planlamanızın çekirdeği olur. Kısacası, işçi bellekleri + veritabanı + önbellek + dosya önbelleği + pay.

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.

Hesaplamaya basit yaklaşalım: Beklediğiniz sipariş/dakika ritmine bakın. Bir siparişin kaç yazma/okuma yaptığı mağazadan mağazaya değişir ama sepet hareketlerinin ve ödeme sonrası adımların toplamda birkaç tur çevirdiğini görürsünüz. Üzerine katalog güncellemeleri, loglamalar ve yedekleme pencereleri bindiğinde, diskin ritmi bozulur. Burada NVMe gibi hızlı diskler ve doğru dosya sistemi ayarları işleri rahatlatır; ama asıl farkı yaratan, akışların çakışmamasını sağlamak ve sıcak veriyi RAM tarafında tutabilmektir.

Ölçmek İçin Küçük Adımlar

Ölçümleri günlük rutininize ekleyin: disk bekleme süresi uzuyorsa, log dosyaları şişiyorsa, veritabanı yazmaları sıraya giriyorsa IOPS yetersizdir. Oturum verilerini ve geçicileri dosya sistemi yerine bellekte tutmak için Redis çok iş görür. Kısa bir dokümana göz atmak isterseniz, Redis’in resmi belgeleri ile hafızada oturum ve cache tutmanın pratik yollarını inceleyebilirsiniz. Ayrıca arşiv ve rapor işlerini yoğun olmayan saatlere taşıyın; kampanya akşamı yedek alıp rapor üretmek, kasaya en uzun kuyruğu o anda kurmak gibidir.

Ağ, CDN ve Veritabanı: Gereksiz Trafiği Kapıdan Çevirmek

İşin bir de dış yüzü var: görseller, CSS’ler, JS’ler, ürün listeleri… Dinamik kısımları koruyup geri kalanları kenara çekebilirseniz, sunucunun üstündeki ağırlık ciddi şekilde azalır. WooCommerce’de her şeyi önden önbelleğe almak mümkün değil, biliyorum. Ama ürün liste sayfaları, blog içerikleri, statik dosyalar ve hatta sepet dışındaki bazı sayfalarda akıllı kurallarla nefis sonuçlar alınıyor. Bu konuda detaylı ve pratik bir yol için, WooCommerce’de HTML cache ve edge kurallarıyla CDN ayarlarını adım adım uygulamak yazısını öneririm.

Veritabanında ise odak şu: gereksiz sorguları azaltmak, indeksleri doğru seçmek, tamponları mantıklı boyutlandırmak. Sorgu başına harcanan süre düştükçe, hem vCPU hem de IOPS ihtiyacı doğal olarak geriliyor. PHP tarafında tekrar tekrar yapılan aynı okumalara objekt önbelleğiyle set çekmek, sipariş sırasında yoğun yazmaları düzgün bir işle akışına bağlamak, trafik dalgalarında kaynak dağılımını dengeler. Küçük dokunuşların toplam etkisi, büyük bir yükseltmenin bıraktığı iz kadar gerçek olur.

Kampanya Günü Stratejisi: Önceden Isıt, Akışı Basitleştir

Kampanya günlerinde bütün şehir aynı düğüne gider gibi akın ediyor. Panik olmamak için iki gün önceden mini bir prova yapın. Önbellekleri ısıtın: en çok ziyaret alan liste ve detay sayfalarına bir tur attırın. Resim kırpma ve indeksleme işleri varsa, geceye bırakın, kampanya saatine değil. PHP işçi sayınızı bir tık artırın ama veritabanına nefes payı bırakın; her şeyi aynı anda büyütmek yerine, darboğaza yakın katmana odaklanın.

Ödeme sırasında gereksiz eklentileri geçici olarak kapatmak, e‑posta kuyruğunu arka plana atmak, log seviyesini düşürmek küçük ama etkili hamlelerdir. Trafik paylaşımını akıllıca yaparsanız, büyük yükseltmelere gerek kalmadan günü atlatırsınız. Eğer mevcut planınız sınırda ise ve yük sık sık tırmanıyorsa, Paylaşımlı bir plandan VPS’e geçerken kesintiyi minimuma indirmek için hazırladığımız kontrol listesi işinizi kolaylaştırır.

İzleme, Yedek ve Güvenlik: Sessiz Kahramanlar

İzleme olmadan kapasite planlaması, farları sönük bir arabayı gece sürmek gibi. CPU kullanımını tek başına değil, çalışan kuyruklarını ve 95. yüzdelik yanıt sürelerini de izleyin. RAM tarafında swap’e en ufak sarkma görürseniz, o anki iş yükünü not alın. Diskte bekleme süresi kritik; IOPS yetmiyorsa burada renk değişir. Uygulama loglarınızı sade tutun ve gerçek hatalara odaklanın.

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

Bir senaryo çizelim. Ürün liste ve detay sayfaları büyük ölçüde önbellekten, sepet ve ödeme ise dinamik. Pik anda sitede 300 kişi var, bunun 30’u aktif arama ve filtrelemede, 18’i sepetle oynuyor, 6’sı ödeme adımında. Ortalama dinamik istekler bir saniye civarında. Buradan kaba bir vCPU tahmini çıkar: en yoğun eşzamanlı ağır istekler sebebiyle, en azından bu eşleşmeyi taşıyacak kadar PHP işçisi ve onları destekleyecek vCPU gerekir. Zorlandığınızda, işçi sayısını bir miktar artırıp, CPU tarafında nefes payı bırakın; ama bunu veritabanı bağlantı sınırlarıyla uyumlu yapın.

RAM tarafında aynı senaryoda, işçi başına bellek tüketimini pratik bir ölçümle bulun ve maksimum beklenen işçi sayısıyla çarpın. Üzerine veritabanı ve Redis için ayırdığınız alanı ekleyin. Sistem dosya önbelleği için de boşluk bırakın. Swap’in kapısını aralamayın; bir kez düştüğünüzde, kampanya anında toparlamak çok zor olur.

IOPS için de küçük bir yöntem yeter: sipariş/dakika ritmini ve sepet hareketlerinin yoğunluğunu gözlemleyin. Günün en kalabalık yarım saatini alın, sipariş akışının en hızlı anını not edin. Eğer o anda loglar yetişemiyor, veritabanı yazmaları gecikiyor veya oturum dosyaları şişiyorsa, disk tarafında hızlanmanız gerekir. Redis ile oturum ve geçicileri belleğe almak, karmaşıklığı ciddi şekilde azaltır.

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. Aynı anda kaç kişinin ağır işlem yaptığını, bu işlemlerin ne kadar sürdüğünü ve veriyi nerede tuttuğunuzu 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…