admin Quick Summary
One of the most common mistakes when choosing a VPS is assuming that more CPU cores, RAM, or NVMe storage automatically improve performance. If the real bottleneck is a slow SQL query, an undersized PHP-FPM pool, missing object caching, or inefficient application code, a more expensive server may deliver little or no improvement.
Support engineers often see servers with CPU utilisation below 15%, plenty of free memory, and large amounts of unused storage, while product pages still take around one second to load. In most cases, the problem turns out to be PHP-FPM configuration, slow database queries, Redis not being used, or swap activity rather than insufficient hardware.
Before comparing VPS plans, identify which resource is actually limiting your application. Check CPU utilisation, memory and swap usage, disk performance, TTFB on dynamic pages, active PHP-FPM workers, database performance, and background jobs. These measurements quickly show which upgrades are necessary and which would simply waste money.
For example, if CPU usage stays below 30%, memory is readily available, swap is unused, yet TTFB still exceeds one second, adding more CPU cores is unlikely to help. Optimising PHP-FPM, enabling Redis Object Cache, improving database performance, or fixing inefficient code will usually have a much greater impact.
A VPS should be sized according to the application’s real workload rather than its largest specification. Eliminate bottlenecks first, measure the server again, and only then increase CPU, memory, or storage. In practice, this approach costs less and ensures that infrastructure resources are used efficiently.
How to Avoid Paying for VPS Resources You Don’t Need
Most unnecessary VPS costs begin before the server is even deployed. Expecting future growth, many businesses immediately choose plans with more CPU cores, RAM, and storage than they actually need. Months later, most of those resources remain unused while the website still performs poorly.
Before selecting a VPS, identify which resources are limiting the application today. If the project already runs on another VPS or dedicated server, review CPU utilisation, memory and swap usage, disk activity, active PHP-FPM workers, TTFB on dynamic pages, database performance, and background jobs. These measurements show where additional resources are justified and where they simply increase costs.
Start by checking CPU usage.
For Linux:
topor
htopIf CPU utilisation stays around 20–30% during normal operation, adding more cores is unlikely to improve performance.
Next, check memory usage.
free -hPay particular attention to swap. Plenty of available memory usually means adding more RAM will have little effect, while regular swap usage indicates that memory has become the next limiting factor.
Then assess storage performance.
iostat -x 1or
vmstat 1If iowait remains low and disk latency is stable, additional storage capacity is unlikely to improve performance. The more important question is whether the current NVMe storage is fast enough.
Finally, examine the application itself. Measure TTFB, check active PHP-FPM workers, and review the database for slow SQL queries. It is common to find a server using only a fraction of its CPU and RAM while delays are caused by inefficient SQL, restrictive pm.max_children settings, or missing Redis object caching.
A typical example occurs after seasonal traffic peaks. Businesses often upgrade from four to eight or more CPU cores, only to discover later that CPU utilisation still averages around 25% while slow catalogue queries continue to delay page generation. Optimising those queries often reduces TTFB far more than upgrading the server.
Before ordering a larger VPS, ask one question: would doubling CPU and memory actually remove the bottleneck identified by your diagnostics? If not, fix that limitation first and reassess the workload afterwards.
The evaluation is complete once you understand CPU usage, memory and swap consumption, storage activity, PHP-FPM concurrency, TTFB, and database behaviour. If the server still has plenty of unused resources while the website remains slow, upgrading to a larger VPS is unlikely to solve the problem.
How to Choose the Right Number of CPU Cores for a VPS
A slow website often leads people to assume they need more CPU cores. In practice, upgrading from four to eight vCPUs frequently produces little improvement because the processor was never the bottleneck. More often, delays are caused by slow SQL queries, PHP-FPM request queues, or inefficient application code.
Start by measuring CPU usage while the website is actually under load. Average utilisation over an entire day tells very little. Monitor the server during peak traffic, imports, cron jobs, backups, indexing, search requests, or checkout activity.
Check current CPU usage.
For Linux:
topor
htopOn multi-core VPSs, examine how work is distributed. One CPU core may remain close to 100% while the others are mostly idle, which is common with single-threaded PHP processes, expensive SQL queries, or sequential background jobs. In this case, adding more cores rarely improves performance.
Next, check the system load.
uptimeor
cat /proc/loadavgIf the load average consistently exceeds the number of available CPU cores, the server is genuinely CPU-bound. Otherwise, processing power is probably not the main limitation.
Then identify the processes using CPU time.
ps aux --sort=-%cpu | head -20If php-fpm dominates, investigate PHP. If mysqld is at the top, focus on database performance. Other heavy consumers may include backups, indexing, Docker containers, antivirus software, or scheduled background jobs.
Review the PHP-FPM slow log together with the MySQL or MariaDB slow query log. High CPU usage is often caused by inefficient PHP code or expensive SQL queries. Adding more CPU cores simply allows inefficient code to consume more resources.
A common example is a WooCommerce import updating tens of thousands of products one by one. Optimising the import to use batch operations often cuts CPU usage dramatically without changing the VPS. The same applies to poorly indexed catalogue queries that briefly push CPU usage to 100% until proper indexes are added.
The opposite situation is equally common. CPU usage stays around 20–30%, yet TTFB exceeds one second. In that case, the delay is usually caused by the database, PHP-FPM worker limits, slow storage, swap activity, or external APIs rather than insufficient CPU.
The evaluation is complete once you have measured CPU usage under peak load, reviewed process distribution, compared load average with available CPU cores, and analysed the PHP-FPM and database slow logs. If CPU utilisation remains close to its limits, adding more cores may help. If processing capacity is still available, identify and eliminate the real bottleneck before upgrading the VPS.
How to Calculate the Right Amount of RAM for PHP-FPM, Your Database, and Redis
Memory shortages are more common than overloaded CPUs. A server may use only 20–30% CPU while the admin panel slows down, checkout stalls, TTFB approaches one second, and swap becomes active. In these situations, RAM rather than processing power is usually the limiting factor.
When sizing a VPS, remember that memory is shared between the operating system, PHP-FPM, MySQL or MariaDB, Redis, the web server, the control panel, cron jobs, monitoring, and the Linux page cache. Estimating RAM only for the website almost always leads to underprovisioning.
Start by checking memory usage.
free -hFocus on available memory and swap. Low free memory alone is not a problem because Linux uses RAM for caching. Regular swap activity, however, usually indicates that the server has exhausted usable memory.
Next, identify the largest memory consumers.
ps aux --sort=-%mem | head -20On most web servers these are PHP-FPM, MySQL or MariaDB, and Redis, although Elasticsearch, Docker containers, backup processes, or the control panel may also consume significant memory.
Then measure the average memory used by a PHP-FPM worker.
ps --no-headers -o rss -C php-fpm | \
awk '{sum+=$1} END {print sum/NR/1024 " MB"}'This reflects the real requirements of your application. A simple WordPress site may use 70–90 MB per worker, while WooCommerce, Moodle, CRM systems, or Laravel applications often require 150–250 MB or more.
Now calculate how much RAM remains for PHP-FPM after accounting for the operating system, database, Redis, Nginx, and other services. Configure pm.max_children according to that value rather than guessing. Setting it too high often pushes the server into swap during peak traffic.
This becomes especially important for WooCommerce and other memory-intensive applications, where larger PHP workers significantly reduce the number of concurrent requests the server can handle.
After calculating the limits, monitor memory during imports, indexing, backups, cron jobs, and peak traffic using:
topor
htopIf available memory falls rapidly, swap usage increases, and kswapd becomes active, RAM has become the primary bottleneck.
The assessment is complete once you know how much memory is used by PHP-FPM, MySQL or MariaDB, Redis, and other services, have calculated a safe pm.max_children value, confirmed that swap is not used during peak workloads, and still have sufficient free memory for filesystem cache and temporary workload spikes. This approach avoids paying for unnecessary RAM while preventing performance problems caused by memory exhaustion.
Should You Choose More Storage or Faster NVMe for Your VPS?
Many people compare VPS plans by storage capacity, assuming a larger disk offers better value. In reality, free space and storage performance are largely unrelated. Support engineers regularly see servers with most of their storage unused while product pages, searches, reports, and backups remain slow because the storage subsystem cannot keep up with the workload.
Start by confirming that storage is actually the bottleneck. If CPU usage is low, memory is sufficient, PHP-FPM is not queuing requests, but TTFB still rises during searches, catalogue filtering, report generation, or backups, investigate disk performance next.
Check disk activity.
iostat -x 1Focus on %util, await, and svctm where available. If utilisation remains close to 100% while await keeps increasing, storage latency is delaying requests even though CPU resources remain available.
Then check iowait with:
topor
vmstat 1If CPU utilisation is low but iowait continues to rise, the processor is spending more time waiting for storage than executing code. Adding CPU cores will have little effect.
Review the MySQL or MariaDB slow query log as well. Slow queries during catalogue filtering, reports, or imports are often caused by storage latency rather than inefficient SQL.
For a more accurate assessment, benchmark random I/O using fio:
fio --name=randrw \
--rw=randrw \
--bs=4k \
--size=1G \
--numjobs=4 \
--runtime=60 \
--time_basedRandom read and write performance is far more important for databases, Redis, CMS platforms, CRM systems, and e-commerce applications than sequential transfer speeds.
This is why storage capacity should not be treated as a performance feature. If your project occupies only 60–80 GB, a fast 100–200 GB NVMe drive is usually a better choice than a much larger but slower disk. Unused storage does not improve performance, while faster NVMe benefits databases, caches, logs, and application data.
Before ordering a VPS, calculate how much storage the project actually uses, including databases, backups, logs, and uploads, then estimate future growth. If only a small proportion of the available space will be used, prioritise a provider that offers fast NVMe storage and allows capacity to be expanded later.
The evaluation is complete once you have reviewed iostat, confirmed that iowait is not a persistent bottleneck, analysed the database slow query log, benchmarked storage with fio, and determined the storage capacity the project genuinely requires. In most production environments, fast NVMe storage with high IOPS delivers a much greater benefit than simply choosing a larger disk.
How Much Headroom Should You Build into Your VPS?
Many VPS sizing mistakes happen before the server is deployed. Some businesses choose almost no spare capacity, while others buy servers several times larger than they currently need. The first approach leads to emergency upgrades, the second to paying for unused resources.
Plan not only for today’s workload but also for realistic growth. If you expect larger catalogues, Redis, Elasticsearch, CRM integrations, PHP upgrades, or increased traffic within the next six to twelve months, include those requirements in your sizing. If the project has been stable for years, there is little benefit in paying for excessive unused capacity.
Compare current resource usage with available capacity. If memory regularly reaches 70–80%, CPU utilisation approaches its limits during peak traffic, or storage I/O becomes saturated, additional headroom is justified. If the server consistently uses only a small fraction of its resources, upgrading is unlikely to improve performance.
Start by checking memory usage.
free -hThen examine CPU utilisation.
topor
htopFinally, review storage activity.
iostat -x 1These checks quickly identify which resource is approaching its limit.
Also monitor long-term trends. Growing databases, increasing numbers of PHP-FPM workers, larger backups, or steadily rising traffic provide a much better basis for capacity planning than guessing future requirements.
A practical approach is to choose a VPS that comfortably supports the next six to twelve months while allowing CPU, RAM, or NVMe storage to be expanded quickly without migration. This avoids paying for resources that may never be used while keeping future upgrades straightforward.
Before ordering a VPS, ask three questions. Which resource is limiting the application today? How quickly is demand growing? Can the VPS be upgraded without moving the project to another server?
The sizing process is complete once you know which resources are approaching their limits, how quickly workload is increasing, and whether the platform can be expanded without downtime. In most cases, scaling the VPS when monitoring shows it is necessary is both more economical and technically more effective than paying for excess capacity in advance.
How to Choose a KVM Linux VPS Without Overpaying
After assessing CPU, memory, and storage, the final step is choosing a VPS that matches the application’s real workload instead of paying for resources that may remain unused for years. By this stage, your diagnostics should already show which resource is actually limiting performance.
Before ordering a KVM Linux VPS, review the results as a whole rather than focusing on individual specifications. If CPU utilisation is low, memory is sufficient, swap is unused, and TTFB remains high, a larger server is unlikely to solve the problem. If monitoring consistently shows CPU saturation, memory pressure, high iowait, or rapidly growing storage requirements, those results should determine the VPS size.
Hardware is only part of the decision. The platform should allow you to configure PHP-FPM, Redis or Memcached, MySQL or MariaDB, OPcache, Nginx, and logging tools. Without that level of control, meaningful optimisation becomes difficult regardless of the server specifications.
Scalability is equally important. As projects grow, databases expand, new services appear, background jobs increase, and traffic rises. Choosing a platform where CPU, RAM, and NVMe storage can be upgraded without migrating the server is usually more cost-effective than paying upfront for resources that may not be needed for years.
Before making the final decision, ask one practical question: if traffic doubled next year, which resource would reach its limit first? If your diagnostics already answer that question, you can size the VPS with confidence.
A better long-term strategy is to choose a server that comfortably supports the next six to twelve months while allowing resources to be expanded as demand grows. This avoids paying for unused capacity while keeping future upgrades simple.
This is the approach typically used when sizing infrastructure for projects at Era.Host, where decisions are based on real workload patterns rather than maximum specifications. CPU, memory, storage performance, and application behaviour are analysed first, and only then is a VPS configuration selected. In many cases, proper sizing and optimisation provide more benefit than simply moving to a larger plan.
The selection is complete once the VPS matches the application’s actual workload, provides sufficient CPU, RAM, storage performance, and full administrative control, while allowing resources to be expanded without migration. The goal is not to buy the largest server available, but the one that solves today’s bottlenecks and can grow with the project when monitoring shows additional resources are genuinely required.
