WordPress Blog, WooCommerce ve SaaS İçin Kaç CPU, Ne Kadar RAM?

Yeni bir WordPress blog, WooCommerce mağaza ya da SaaS ürünü planlarken en çok takılan noktalardan biri şudur: “Kaç CPU almalıyım, ne kadar RAM yeter?” Proje toplantılarında bütçe konuşulurken çoğu zaman tasarım, özellik listesi ve pazarlama detaylı konuşulur; altyapı tarafı ise “şimdilik küçük bir VPS alırız, büyürse bakarız” seviyesinde kalır. Sonra ilk kampanyada site yavaşlar, ödeme adımları takılır, dashboard ekranları saniyelerce döner ve konu ister istemez acil kriz toplantısına döner.

Bu yazıda DCHost ekibi olarak yıllardır sahada gördüğümüz gerçek senaryolardan yola çıkıp; WordPress blog, WooCommerce ve küçük/orta ölçekli SaaS uygulamaları için VPS tarafında kaç CPU, ne kadar RAM ve nasıl bir yaklaşım gerekli, adım adım netleştireceğiz. Amacımız “ezber değerler” önermekten çok, kendi projenizi oturup hesaplayabileceğiniz pratik bir çerçeve vermek. Böylece hem gereğinden büyük sunucuya gereksiz para ödemez, hem de trafik geldiğinde boğulan bir projeyle uğraşmak zorunda kalmazsınız.

CPU ve RAM Temel Mantığı: vCPU, İş Parçacığı ve Bellek Tüketimi

Detaylı senaryolara geçmeden önce, VPS tarafında CPU ve RAM’in ne anlama geldiğini netleştirelim. DCHost üzerinde aldığınız bir VPS’te tipik olarak vCPU (sanal CPU çekirdeği) ve GB cinsinden RAM görürsünüz.

• vCPU: Fiziksel işlemcinin paylaştırılmış mantıksal çekirdekleridir. Web tarafında düşünebileceğiniz en basit karşılık, aynı anda çalışabilecek PHP-FPM veya uygulama iş parçacığı (worker) sayısıdır.
• RAM: Uygulamanızın, veritabanınızın ve işletim sisteminin bellekte tuttuğu her şeyin toplam alanı. RAM bittiğinde sistem SWAP’e düşer, bu da özellikle NVMe olmayan sistemlerde ciddi yavaşlama ve hatta OOM killer ile servislerin kapanmasına kadar gider.

CPU genelde ani yüklerde boğulur (kampanya, haber patlaması, yoğun API trafiği), RAM ise sürekli birikim problemi gibi davranır (cache şişmesi, PHP-FPM prosesleri, büyüyen veritabanı buffer’ları). Bu yüzden ikisini birlikte düşünmek gerekir.

VPS kaynaklarını nasıl izleyeceğinizi ve hangi metriklere bakmanız gerektiğini ayrıntılı görmek isterseniz, VPS kaynak kullanımı izleme rehberi yazımızı da mutlaka okumanızı öneririm.

WordPress Blog İçin Kaç CPU, Ne Kadar RAM?

WordPress blog tarafında en kritik parametreler; eşzamanlı ziyaretçi sayısı, kullanılan tema/eklenti ağırlığı ve önbellekleme stratejinizdir. Aynı ziyaretçi sayısında bile, hafif bir tema + iyi bir cache kurgusu ile kaynak tüketimi dramatik şekilde düşer.

Küçük Kişisel Blog (Günlük 500–2.000 Ziyaret)

Senaryo: Standart bir WordPress kurulumu, hafif bir tema, birkaç temel eklenti (SEO, cache, güvenlik). Günlük 500–2.000 civarı ziyaret, eşzamanlı 5–15 kullanıcı.

• Önerilen minimum VPS: 1 vCPU, 1 GB RAM
• Konforlu başlangıç: 1–2 vCPU, 2 GB RAM

1 vCPU, düzgün yapılandırılmış bir PHP-FPM ve tam sayfa önbellekleme ile (LiteSpeed Cache, Nginx FastCGI cache vb.) bu ölçek için çoğu zaman yeterlidir. RAM tarafında ise 1 GB altı, servisler ve işletim sistemi payını da düşününce risklidir. 2 GB RAM, MySQL/MariaDB ve PHP-FPM için çok daha rahat bir alan sağlar.

WordPress tarafında PHP-FPM, OPcache ve Redis gibi bileşenleri doğru ayarladığınızda aynı donanımdan çok daha fazla verim alabilirsiniz. Detaylı sunucu tarafı ayarları için WordPress için sunucu tarafı optimizasyon rehberi size iyi bir rehber olacaktır.

Orta Ölçekli İçerik Sitesi (Günlük 5.000–20.000 Ziyaret)

Senaryo: Kategorili içerik sitesi, hafif trafik patlamaları, sosyal medyadan gelen dalgalı trafik. Eşzamanlı 30–100 kullanıcı, yoğun zamanlarda 200’e pik.

• Önerilen başlangıç: 2 vCPU, 4 GB RAM
• Yoğun yayın yapanlar için: 4 vCPU, 8 GB RAM

Bu ölçekte asıl farkı yaratanlar:

• İyi bir tam sayfa cache (anonim kullanıcıların çoğunu cache’den beslemek)
• Veritabanı sorgularını çok yormayan tema/eklenti seçimi
• Medya dosyalarını CDN veya object storage’a offload etmek

Eğer haber tarzı, çok sık güncellenen içerikler yayınlıyorsanız, cache süresini doğru dengelemek ve veritabanı yükünü hafifletmek kritik hale gelir. Yüksek trafikli haber ve blog siteleri için hazırladığımız detaylı rehber bu noktada güzel bir tamamlayıcı olacaktır.

Yüksek Trafikli Haber / Blog (Günlük 20.000–100.000+ Ziyaret)

Senaryo: Birden çok editör, sık içerik girişi, anlık trafik patlamaları (gündem haberleri, kampanyalar). Eşzamanlı 200–1.000+ kullanıcı.

• Başlangıç noktası: 4 vCPU, 8 GB RAM, NVMe disk
• Daha agresif senaryolar: 6–8 vCPU, 12–16 GB RAM

Bu seviyede artık sadece CPU ve RAM değil, disk IOPS (özellikle MySQL/MariaDB için) ve ağ gecikmesi de oyuna girer. NVMe diskler, rastgele okuma/yazma performansları sayesinde veritabanı yükünde ciddi fark yaratır. Ayrıca:

• Redis/Memcached ile nesne önbelleği
• Query cache yerine doğru indekslenmiş veritabanı
• Statik dosyalar için bir CDN katmanı

Eğer bu seviyedeyseniz, sadece tek VPS değil; veritabanını ayrı bir sunucuya alma, replikasyon ve cache katmanlarını da konuşmak anlamlı olmaya başlar.

WooCommerce Mağazalar İçin CPU ve RAM Hesabı

WooCommerce, düz bir blog’a göre çok daha ağır bir iş yüküdür. Çünkü:

• Sepete ekleme, kupon, stok kontrolü, kargo hesaplama gibi işlemler dinamik ve CPU maliyetlidir.
• Her sipariş veritabanına çok daha fazla yazma operasyonu yapar.
• Ödeme sayfaları genelde cache’lenemez; her istek gerçek PHP çalıştırır.

Bu yüzden günlük ziyaretçi sayısı aynı olsa bile, WooCommerce genelde bir blog’dan en az 2 kat daha agresif kaynak tüketir. Detaylı formüller ve örnekler için ayrıca WooCommerce kapasite planlama rehberi yazımıza da göz atabilirsiniz.

Mikro Mağaza (Günlük 50–200 Sipariş)

Senaryo: Yeni açılmış butik mağaza, sınırlı ürün sayısı (50–200 ürün), aynı anda genellikle 10–30 ziyaretçi, zaman zaman 50–60’a çıkan pikler.

• Önerilen başlangıç: 2 vCPU, 4 GB RAM, NVMe disk
• Daha rahat alan isteyenler için: 3–4 vCPU, 6–8 GB RAM

Burada asıl sıkıntı, kampanya veya influencer paylaşımı gibi beklenmedik anlık piklerdir. Normalde CPU %15–20 seyrederken, bir anda checkout sayfasında onlarca eşzamanlı kullanıcı görebilirsiniz. 2 vCPU bu tip ani yükleri çok büyümeden karşılayabilir, ancak 4 GB RAM altına düşmemek sipariş yoğunluğunda veritabanı ve PHP süreçlerinin sıkışmaması için kritiktir.

Büyüyen E‑Ticaret (Günlük 200–1.000 Sipariş)

Senaryo: Orta ölçekli e‑ticaret sitesi, binlerce ürün, yoğun kategori/filtre kullanımı, entegrasyonlar (pazaryeri, muhasebe, kargo vs.). Eşzamanlı 100–400 kullanıcı.

• Önerilen mimari (tek VPS’te başlarken): 4 vCPU, 8 GB RAM, yüksek IOPS’lu NVMe disk
• Büyümeye hazır mimari: 6–8 vCPU, 12–16 GB RAM ve veritabanını ayrı VPS’e ayırma planı

Bu ölçekten itibaren şu konuları da masaya koymanız gerekir:

• MySQL/MariaDB için ayrı sunucuya geçmek veritabanını uygulama sunucusundan ayırmanın mantıklı olduğu eşiklerden biridir.
• WooCommerce için özel veritabanı indeksleme ve sorgu optimizasyonu (detaylı rehberte anlattığımız gibi) ciddi CPU kazandırır.
• Redis tabanlı nesne önbelleği ve tam sayfa cache, özellikle anonim trafik tarafında CPU yükünü dramatik azaltır.

Kampanya ve Sezonluk Trafik Patlamaları

WooCommerce tarafında en çok can yakan şey planlanmamış kampanya pikleridir. Normalde yeterli olan kaynaklar, 2–3 kat trafik artışında boğulabilir. Bu yüzden kapasite planlarken her zaman:

• Normal gün CPU/RAM yükünün en fazla %60–70 civarında kalmasını
• Kampanya günlerinde ise kısa süreli %80–90 piklerini tolere edebilecek rezerviniz olmasını

hedeflemek sağlıklıdır. Özellikle kampanya bazlı çalışan e‑ticaret projeleri için sezonluk trafik patlamalarına hazırlık rehberindeki önbellek ve ölçekleme stratejilerini uygulamanızı öneririz.

SaaS Uygulamaları İçin CPU ve RAM Planlama Yaklaşımı

SaaS dünyasında iş yükü WordPress/WooCommerce’e göre çok daha değişken ve uygulama mimarisine bağımlıdır. Yine de birkaç tipik senaryodan hareketle bir çerçeve çizebiliriz.

MVP / Early‑Stage SaaS (İlk 50–100 Müşteri)

Senaryo: Tek VPS üzerinde çalışan monolitik bir PHP/Laravel, Node.js veya benzeri uygulama. Aynı anda aktif 10–50 kullanıcı, arka planda çalışan sınırlı sayıda cron/queue işi.

• Önerilen başlangıç: 2 vCPU, 4 GB RAM
• Daha güvenli alan: 3–4 vCPU, 6–8 GB RAM

Burada önemli olan, ilk günden mikro servis mimarisine girmek değil, tek bir orta boy VPS üzerinde:

• Uygulama proseslerini (PHP-FPM, Node.js worker’ları vb.) mantıklı sayıda tutmak
• Veritabanı ve cache (Redis vb.) için yeterli RAM bırakmak
• Queue/cron işlerini web isteklerinden ayırmak

Küçük SaaS projeleri için tek VPS, çoklu VPS ve yönetilen bulut senaryolarını karşılaştırdığımız SaaS için en doğru hosting mimarisi yazısına da göz atabilirsiniz.

100–500 Aktif Eşzamanlı Kullanıcı Seviyesi

Senaryo: Artık onlarca değil, yüzlerce aktif oturumun aynı anda panel, rapor ekranları veya gerçek zamanlı bileşenlerle sistemi kullandığı noktadasınız. Arka planda yoğun queue işleri (raporlama, entegrasyon, PDF oluşturma vb.) çalışıyor.

• Önerilen kaynak bandı: 4–8 vCPU, 8–16 GB RAM
• Mimari öneriler:

• Veritabanını ayrı bir VPS’e taşıma
• Queue/worker süreçleri için ayrı bir VPS ya da en azından ayrı CPU havuzu
• Redis/Memcached ile session ve cache yönetimini diske bırakmamak

Bu seviyede “her şeyi tek VPS’e yığma” stratejisi kısa sürede tıkanır. Yükü uygulama, veritabanı ve background işler olarak ayırıp, her katman için ayrı CPU/RAM planlamak çok daha sağlıklı ilerlemenizi sağlar. Çok kiracılı (multi‑tenant) SaaS mimarileri ve doğru altyapı seçimleri için bu kapsamlı SaaS rehberimizi de inceleyebilirsiniz.

İstek Başına Kaynak Tüketimi Mantığı

SaaS’ta kaba bir hesap yapmak için şu düşünce deneyini kullanabilirsiniz:

1. Uygulamanızda tipik bir sayfa isteğinin CPU’da ne kadar sürdüğünü ölçün (örneğin 50 ms).
2. Bir saniyede bir vCPU teorik olarak 1.000 ms işlem yapabilir. 50 ms’lik işlemler için bu, saniyede 20 istek kapasitesi demektir.
3. 4 vCPU için teorik üst sınır saniyede 80 istektir. Gerçekte bunun %50–60’ını güvenli kabul edin.

Böylece, beklenen eşzamanlı kullanıcı ve istek sayısından yola çıkarak, kabaca kaç vCPU’ya ihtiyacınız olduğunu tahmin edebilirsiniz. Elbette bu, veritabanı ve I/O yükünü göz ardı eden basitleştirilmiş bir modeldir; ama ilk planlama için oldukça faydalıdır.

RAM Hesabı: PHP-FPM, Veritabanı ve Cache’in Payını Bölmek

RAM planlarken en sık yapılan hata, “8 GB RAM aldık, nasıl olsa yeter” diye düşünmek ve bu 8 GB’ın kimler arasında bölüneceğini hiç hesaplamamaktır. Oysa tipik bir WordPress/WooCommerce veya SaaS VPS’inde RAM şu bileşenler arasında paylaşılır:

• İşletim sistemi ve temel servisler (SSH, systemd, log servisleri vb.)
• Web sunucusu + PHP-FPM veya uygulama runtime’ı (Node.js, Python vb.)
• Veritabanı (MySQL/MariaDB/PostgreSQL)
• Cache sistemleri (Redis, Memcached)
• Arka plan işler / queue worker’ları

Basit bir örnek:

• Toplam RAM: 8 GB
• OS + temel servisler: ~1 GB
• MySQL: 2–3 GB (buffer pool, cache’ler vs.)
• Redis: 0.5–1 GB
• Geriye PHP-FPM ve diğer uygulamalar için ~3 GB kalır

Eğer PHP-FPM prosesleriniz sıradan bir WordPress kurulumu için proses başına ortalama 50–80 MB RAM tüketiyorsa, 3 GB alanda teorik olarak 40–60 aktif PHP sürecine yer açabilirsiniz. Bu eşzamanlı dinamik istek kapasitenizi doğrudan etkiler.

RAM bittiğinde Linux çekirdeği prosesleri öldürmek zorunda kalır. Bu sırada hangi uygulamaların kapanacağını önceden tahmin etmek zordur. OOM killer davranışı ve SWAP kullanımının detayları için RAM, SWAP ve OOM killer yönetimi rehberimizi inceleyebilirsiniz.

Kaynak Planlamayı Adım Adım Hesaplama: Pratik Çerçeve

Şimdiye kadar farklı senaryolar için “iyi başlangıç” değerleri verdik. Kendi projeniz için daha net bir hesap yapmak isterseniz, aşağıdaki çerçeveyi kullanabilirsiniz.

1. Trafik ve Kullanıcı Davranışını Tahmin Et

• Günlük beklenen ziyaretçi sayısı (örneğin 5.000 kişi)
• Kullanıcı başına ortalama sayfa görüntüleme (örneğin 3–4 sayfa)
• Yoğun saatlerde oluşacak eşzamanlı kullanıcı sayısı (genelde günlük toplamın %5–10’u civarı)

“Yeni web sitesi için CPU, RAM ve trafik nasıl hesaplanır” konusunu özellikle merak ediyorsanız, ayrı detaylı rehberimizi okuyup burada anlattıklarımızla birleştirebilirsiniz.

2. Sayfa Türlerine Göre Dinamik İstek Yükünü Belirle

Özellikle WooCommerce ve SaaS tarafında her sayfa eşit değildir:

• Listeleme / blog yazısı gibi cache’lenebilir sayfalar
• Sepet, ödeme, kullanıcı hesabı, panel gibi cache’lenemeyen sayfalar
• Ağır rapor veya sorgu üreten sayfalar

Toplam isteklerin ne kadarlık kısmının gerçekten PHP/uygulama tarafından işlendiğini (cache bypass) tahmin etmek, CPU hesabınızı daha gerçekçi yapmanızı sağlar. İleride log analizi ile bu oranları net ölçmek için sunucu loglarını okuma rehberi de işinize yarayacaktır.

3. vCPU Hesabı: Eşzamanlı İstek ve İşlem Süresi

Basit ama işe yarayan bir yaklaşım:

1. Canlıya çıkmadan önce staging ortamında bir load test yapın (k6, JMeter, Locust vb.).
2. Tipik bir dinamik isteğin (örneğin ödeme sayfası) ortalama CPU süresini ve yanıt süresini ölçün.
3. Yoğun zamanda beklediğiniz eşzamanlı dinamik istek sayısını bu değerlere bölerek teorik CPU ihtiyacınızı çıkarın.

Bu adımları daha sistematik yapmak için trafik patlamasından önce load test rehberimizden yararlanabilirsiniz. Çıkardığınız sonuca %30–40 güvenlik payı eklemek, üretim ortamında ani pikleri tolere etmenize yardımcı olur.

4. RAM Hesabı: Bileşenlere Kota Tanımla

Toplam RAM’inizi şu şekilde zihninizde bölün:

• OS + temel servisler: %10–15
• Veritabanı: %30–40
• Cache sistemleri: %10–20
• Uygulama (PHP-FPM, Node.js, worker’lar): %30–40

Örneğin 8 GB RAM’iniz varsa:

• ~1 GB OS
• ~3 GB veritabanı
• ~1 GB Redis
• ~3 GB uygulama süreçleri

Daha sonra PHP-FPM veya benzeri worker’lar için proses başına ortalama RAM tüketimini ölçüp, kaç eşzamanlı proses açabileceğinizi belirleyin. Bu sayı doğrudan “eşzamanlı dinamik istek” kapasitenizi belirler.

Sık Yapılan Hatalar ve Güvenli Pay Bırakma Stratejisi

Kaynak planlama yaparken sahada en sık gördüğümüz hataları ve nasıl kaçınabileceğinizi kısaca toparlayalım.

“Şimdilik En Küçüğü Yeter” Yaklaşımı

Özellikle WooCommerce ve SaaS projelerinde, paylaşımlı hostingten çok küçük bir VPS’e geçip sorunların çözüleceğini ummak yaygın bir hata. Gerçekte ise:

• Paylaşımlı hostingte CPU ve RAM limitleri yüzünden boğulan bir site, 1 vCPU/1 GB VPS’te de boğulur.
• Farkı yaratan şey genelde sadece daha büyük kaynak değil; doğru cache, veritabanı optimizasyonu ve mimari ayrışmadır.

Paylaşımlı hostingten ne zaman ve nasıl VPS’e geçmeniz gerektiğini adım adım anlattığımız sorunsuz geçiş rehberi, bu karar noktasında çok işinize yarar.

Sürekli %80–90 CPU Kullanımını “Kaynaklar Boşa Gitmesin” Diye Normalleştirmek

CPU’nun sürekli %80–90 bandında olması, sistemin her an boğulmaya hazır olduğu anlamına gelir. Kısa süreli pikler için sorun olmayabilir ama:

• Deploy, yedek alma, cron/queue patlamaları gibi ek yükler geldiğinde hemen 100%’e vurur.
• Yanıt süreleri uzar, kullanıcı tarafında “site çok yavaş” şikayetleri başlar.

Sağlıklı bir üretim ortamında normal yükte %40–60 civarı, yoğun anlarda ise kısa süreli %80–90 pikleri idealdir. Uzun süreli %90+ değerler, genellikle bir üst paket veya ek node zamanının geldiğine işaret eder.

RAM’i Swap ile Telafi Edebileceğini Düşünmek

Swap, RAM’in “uzantısı” değildir; acil durum tamponudur. Özellikle NVMe olmayan disklerde yoğun Swap kullanımı:

• Yanıt sürelerini saniyelere çıkarır.
• Veritabanı ve PHP süreçlerini sürekli diskle konuşturduğu için I/O boğazına yol açar.

Swap’i mutlaka tanımlayın, ama “eksik RAM’i swap ile kapatırım” yaklaşımından kaçının. Yük altında swap kullanımınız düzenli olarak yükseliyorsa, RAM artırma veya uygulama optimizasyonu (örneğin daha az PHP-FPM havuzu, daha hafif sorgular) zamanı gelmiştir.

DCHost Üzerinde Pratik Planlama: Blog, WooCommerce ve SaaS

Teoriyi konuşmak kadar, bunu gerçek DCHost altyapısında nasıl uygulayacağınızı da konuşmak önemli.

• WordPress blog: Küçük/orta ölçekli projeler için 1–2 vCPU, 2–4 GB RAM’li giriş seviye VPS’ler genelde fazlasıyla yeterli olur. Trafiğiniz büyüdükçe CPU ve RAM’i kademeli artırabilirsiniz.
• WooCommerce: En baştan 2 vCPU, 4 GB RAM altında başlamamanızı tavsiye ediyoruz. Büyüdükçe veritabanını ayrı bir VPS’e taşıyabileceğiniz mimariyi önceden planlamak büyük kolaylık sağlar.
• SaaS: MVP aşamasında 2 vCPU, 4 GB RAM’li tek VPS modeli oldukça verimlidir. Kullanıcı sayısı arttıkça, veritabanı ve queue işlerini ayrı VPS’lere ayırmaya hazır olacak şekilde tasarlamak en sağlıklı yoldur.

DCHost olarak sadece VPS, dedicated sunucu ve colocation hizmeti sunmakla kalmıyor; aynı zamanda gerçek kullanım verilerinize bakarak somut kapasite planlama önerileri de yapıyoruz. Uzun vadede maliyeti düşük, performansı yüksek bir altyapı kurmak istiyorsanız, mevcut projenizin trafiği ve hedeflerini bizimle paylaşmanız yeterli.

Özet ve Sonraki Adımlar

WordPress blog, WooCommerce mağaza veya SaaS ürünü fark etmeksizin, “kaç CPU, ne kadar RAM” sorusunun sihirli tek bir cevabı yok; ama sağlıklı bir çerçevesi var. Bu yazıda:

• Farklı trafik seviyeleri için WordPress blog’larda 1–4+ vCPU ve 2–8+ GB RAM’in nerede anlamlı olduğunu,
• WooCommerce için sipariş ve kampanya yüküne göre 2–8+ vCPU, 4–16+ GB RAM ölçeklerini,
• SaaS uygulamalarında MVP’den 100+ eşzamanlı kullanıcı seviyesine kadar CPU/RAM planlamasını,
• CPU ve RAM’i basit formüllerle nasıl kabaca hesaplayabileceğinizi,
• Swap, OOM, sürekli yüksek CPU gibi tuzaklardan nasıl kaçınacağınızı

özetlemeye çalıştık. Bundan sonraki adımınız, projeniz için gerçekçi trafik hedefleri koymak, basit bir kapasite hesabı yapmak ve mümkünse canlıya çıkmadan önce küçük bir load test ile varsayımlarınızı test etmek olmalı.

Eğer “Bunların hepsini takip etmekle uğraşamam, benim yerime biri baksa” diyorsanız, DCHost üzerindeki VPS ve dedicated sunucu çözümlerimizi inceleyebilir, projenizin detaylarını bizimle paylaşarak birlikte en doğru konfigürasyonu tasarlayabiliriz. Doğru boyutlandırılmış bir VPS, hem performans hem de maliyet tarafında size uzun vadeli konfor sağlar; gereksiz büyük makinelerle bütçenizi yakmadan, küçük makinelerle de kullanıcılarınızı üzmeden, tam ortasını birlikte tutturmak mümkün.