Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Günlük ziyaretçi sayısı tek başına CPU/RAM boyutlandırma metriği değildir. Aynı 100 bin ziyaretçi cache'li içerik sitesinde ve kişiselleştirilmiş WooCommerce checkout sisteminde tamamen farklı kaynak tüketir.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
WordPress, WooCommerce, PHP ve API için CPU/RAM ihtiyacını ziyaretçi sayısı yerine concurrency, worker, cache, DB ve request maliyetiyle hesaplayın.
Günlük ziyaretçi sayısı tek başına CPU/RAM boyutlandırma metriği değildir. Aynı 100 bin ziyaretçi cache'li içerik sitesinde ve kişiselleştirilmiş WooCommerce checkout sisteminde tamamen farklı kaynak tüketir.
Doğru boyutlandırma concurrent request, cache hit ratio, PHP/Node worker sayısı, request başına memory/CPU süresi, DB query maliyeti ve background job'ları birlikte ele alır.
Aylık 1 milyon ziyaretçi kulağa büyük gelir; ancak trafik gün içine eşit yayılıyor ve sayfaların yüzde 95'i CDN/cache HIT ise origin aynı anda çok az dynamic request görebilir. Tersine kampanya anında 500 checkout request'i aynı dakikada alan mağaza daha küçük toplam trafiğe rağmen zorlanabilir.
İlk ölçüm peak requests per second, active users, PHP/Node worker queue ve p95 response time olmalıdır.
Toplam RAM yalnız PHP'ye verilmez. Kernel/OS, web server, database buffer pool, Redis, PHP-FPM workers, monitoring agent ve filesystem page cache aynı belleği paylaşır. Swap sürekli kullanılıyorsa yalnız 'RAM dolu' değil hangi süreç ve cache'in büyüdüğü incelenmelidir.
PHP-FPM'de her worker 80-200 MB kullanıyorsa 20 worker teorik olarak 1.6-4 GB yalnız PHP process belleği tüketebilir. Kendi uygulamanızda `ps`/status ile gerçek RSS ölçülmelidir; sabit internet rakamı kopyalanmamalıdır.
free -hps --sort=-rss -eo pid,comm,rss,%mem | head -20vmstat 1 10Bir PHP request 20 ms CPU kullanıyorsa bir core teorik olarak çok daha fazla request çevirebilir; 400 ms CPU kullanan ağır uncached request aynı concurrency'de core'ları hızla doldurur. Bu yüzden APM/profiling ve load test olmadan '10 bin ziyaretçi = 4 core' formülü güvenilir değildir.
Single-thread performansı da önemlidir. Daha fazla core yalnız paralel request sayısını artırır; tek request'in yavaş çalışan PHP kodunu otomatik hızlandırmaz.
Full-page cache dynamic PHP ve DB çalıştırmadan HTML döndürebiliyorsa CPU ve DB yükünü dramatik azaltabilir. Redis object cache DB query tekrarlarını azaltabilir ama RAM tüketir. CDN static asset bandwidth'ini origin'den alabilir.
Bu yüzden '2 GB RAM hosting' ile '2 GB RAM VPS' birebir karşılaştırılamaz. Hosting platformunda cache, DB ve mail servisleri ayrı altyapıda veya optimize edilmiş olabilir; VPS'te tüm servisler aynı RAM'i paylaşabilir.
Aşağıdaki aralıklar satın alma garantisi değil load-test başlangıç noktasıdır. Optimize edilmiş cache'li küçük WordPress için 1-2 vCPU / 2-4 GB; WooCommerce veya çok eklentili site için 2-4 vCPU / 4-8 GB; yoğun dynamic/API workload için 4+ vCPU / 8+ GB gibi başlangıç profilleri düşünülebilir. Gerçek karar ölçümle verilir.
Production'a kontrolsüz saldırı üretmeyin. Staging veya bakım penceresinde k6/ab/wrk gibi araçlarla gerçek kullanıcı akışına benzeyen sınırlı test yapın. Cache HIT testini checkout/API testiyle karıştırmayın. Aynı anda CPU, RAM, DB, disk ve response percentile izleyin.
Hedef yalnız 'kaç request çöktü' değildir; p95/p99 latency'nin hangi concurrency'de bozulduğu ve hangi kaynağın saturation'a ulaştığı bulunmalıdır.
Kaynak limit logları düzenli vuruluyor, PHP worker/entry process kuyruğu oluşuyor, özel daemon/Docker gerekiyor, DB/cache yapılandırması üzerinde daha fazla kontrol istiyorsanız VPS/VDS mantıklı olabilir. Sırf CPU grafiği bir kez yükseldi diye geçiş yapmak gerekmez.
| Workload | Başlangıç CPU | Başlangıç RAM | En önemli ölçüm |
|---|---|---|---|
| Cache'li WordPress | 1-2 vCPU | 2-4 GB | TTFB + worker queue |
| WooCommerce | 2-4 vCPU | 4-8 GB | Dynamic p95 + DB |
| API / yoğun PHP | 4+ vCPU | 8+ GB | CPU/request + concurrency |
Tek bir benchmark, port etiketi veya CPU marka adıyla satın alma kararı vermeyin. Aynı testleri farklı saatlerde tekrarlayın; destructive disk testlerini production verisi üzerinde çalıştırmayın ve sağlayıcının kaynak/fair-use politikasını yazılı doğrulayın.
Tek başına ziyaretçi sayısından hesaplanamaz. Peak concurrency, cache hit, request memory ve DB yükü ölçülmelidir.
Optimize edilmiş tek küçük site için başlangıç olabilir; DB, panel, mail ve eklentiler aynı VM'de çalışıyorsa pay hızla azalır.
Projenizin yazılımını, eşzamanlı kullanıcı sayısını, disk/veritabanı yükünü ve lokasyon hedefini iletin; yalnız RAM/Core sayısına değil gerçek darboğaza göre sunucu sınıfını belirleyin.