Turkey (Turkish)
Germany (German)
Worldwide (English)
Daily visitor count alone is not a CPU/RAM sizing metric. The same 100k visits can have radically different cost on a cached content site versus personalized WooCommerce checkout.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Size CPU/RAM for WordPress, WooCommerce, PHP and APIs using concurrency, workers, cache, database and request cost rather than visitor counts alone.
Daily visitor count alone is not a CPU/RAM sizing metric. The same 100k visits can have radically different cost on a cached content site versus personalized WooCommerce checkout.
Proper sizing considers concurrent requests, cache hit ratio, worker count, per-request memory/CPU time, database cost and background jobs.
One million monthly visits can be easy if traffic is spread and 95% of pages are cache hits. A smaller store receiving hundreds of dynamic checkout requests in one minute can be much harder.
Start with peak requests per second, active users, worker queues and p95 response time.
Total RAM is shared by OS/kernel, web server, database buffers, Redis, PHP-FPM workers, monitoring and filesystem cache. Persistent swap requires identifying which component is consuming memory.
If PHP-FPM workers consume 80-200 MB each, 20 workers can require roughly 1.6-4 GB just for PHP processes. Measure real RSS on your application rather than copying generic figures.
free -hps --sort=-rss -eo pid,comm,rss,%mem | head -20vmstat 1 10A request consuming 20 ms of CPU is very different from one consuming 400 ms. Therefore formulas such as 10k visitors equals 4 cores are unreliable without profiling and load testing.
Single-thread performance matters too. More cores increase parallel capacity but do not automatically speed up one slow PHP request.
Full-page cache can avoid PHP and database execution, dramatically reducing CPU/DB load. Redis object cache reduces repeated queries but uses RAM. A CDN can offload static bandwidth.
A 2 GB hosting account and a 2 GB VPS are not directly comparable. Managed hosting may offload or optimize services, while a VPS may run everything inside the same memory budget.
The ranges below are not guarantees, only load-test baselines. A small cached WordPress site might start around 1-2 vCPU/2-4 GB, WooCommerce or plugin-heavy sites around 2-4 vCPU/4-8 GB, and dynamic/API workloads around 4+ vCPU/8+ GB. Measure before final sizing.
Do not generate uncontrolled load on production. Use staging or a maintenance window and model real user flows. Separate cache-hit tests from checkout/API tests and monitor CPU, RAM, DB, disk and response percentiles.
The goal is to discover where p95/p99 latency degrades and which resource saturates, not merely how many requests cause a crash.
A VPS/VDS becomes reasonable when resource limits are repeatedly hit, worker queues form, custom daemons/Docker are needed or you need deeper DB/cache control. One CPU spike is not enough reason.
| Workload | Starting CPU | Starting RAM | Most important measurement |
|---|---|---|---|
| Cached WordPress | 1-2 vCPU | 2-4 GB | TTFB + worker queue |
| WooCommerce | 2-4 vCPU | 4-8 GB | Dynamic p95 + DB |
| API / heavy PHP | 4+ vCPU | 8+ GB | CPU/request + concurrency |
Do not buy based on one benchmark, port label or CPU brand. Repeat tests at different times, avoid destructive storage tests on production data, and verify provider resource/fair-use policies in writing.
Visitor count alone is insufficient. Measure peak concurrency, cache hit ratio, per-request memory and database load.
It can be a starting point for one optimized small site, but database, panel, mail and plugins consume the same memory budget.
Share your software stack, concurrency, storage/database load and target region; size the server around the real bottleneck rather than RAM/core labels alone.