How to Choose a VPS for a Website with Growing Traffic

Quick Summary

Most websites do not outgrow their hosting environment overnight. Performance issues tend to build up gradually. At first, pages become noticeably slower during busy evening hours. Then the administration panel starts taking four to six seconds to respond, product imports and catalogue updates take much longer than before, 503 errors begin appearing in the logs, PHP-FPM starts reaching its process limit, and the database increasingly becomes a source of latency. From the outside, the behaviour seems inconsistent. The site performs well in the morning and throughout most of the day, but once traffic peaks, users begin reporting slow page loads and intermittent delays.

The usual reaction is to order a VPS with more CPU cores or the largest amount of RAM available, often without investigating what is actually happening. A few months later, the same symptoms return. The new server also slows down because the real issue was never a lack of hardware. The underlying bottleneck simply wasn't identified. In support environments, diagnosing why a website has outgrown its current infrastructure is far more common than replacing servers because they have genuinely reached their limits.

Before choosing a VPS, assess the current state of your application. Measure TTFB in the morning, afternoon and during peak traffic. Review your web server logs for 503 responses or upstream timed out messages. Examine the PHP-FPM slow log, the MySQL or MariaDB slow query log, memory usage, swap activity, iowait, storage performance and database size. If Redis is deployed, confirm that the application is actually using object caching instead of querying the database on every request.

It is equally important to understand the type of workload your website generates. One site may serve 10,000 page views per day while placing very little load on the server thanks to effective caching. Another may overwhelm the CPU with far fewer visitors because every request triggers product filtering, search queries, intensive PHP execution, API calls, data imports or background jobs. This is why selecting a VPS based solely on visitor numbers, storage capacity or virtual CPU count is rarely the right approach.

A sensible VPS migration begins with analysing the existing environment rather than comparing hosting plans. Once you know what is actually limiting your site's performance, choosing a configuration that will comfortably handle traffic growth over the next several months becomes much easier. That approach helps avoid repeated migrations, unexpected performance issues during peak periods and the costly mistake of replacing infrastructure simply because the original server was sized without understanding the application's real workload.

As the support team at Era.Host has seen repeatedly, projects that are upgraded based on measured bottlenecks rather than assumptions tend to scale far more predictably and require far fewer emergency migrations as traffic grows.

How to Tell When Shared Hosting Can No Longer Handle Your Traffic Growth

Many website owners only start thinking about moving to a VPS after the first 503 errors appear. In reality, the warning signs usually show up much earlier. The website becomes noticeably slower during peak traffic hours, users begin reporting inconsistent page loads, checkout or search functions occasionally freeze, and the CMS administration panel starts taking several seconds to respond. If the site is fast in the morning but response times increase dramatically in the evening, the problem is rarely the visitor's internet connection. More often, it means the hosting environment is no longer able to cope with the current workload.

The first step is to measure response times at different times of day. A single test is not enough. Run the same measurements in the morning, afternoon and during peak traffic for the homepage, category pages, product pages, search results and the administration panel if it requires authentication. If TTFB consistently increases during busy periods, the server is already struggling to generate pages under load.

For a quick test, run:

curl -o /dev/null -s -w \ "TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \ https://example.com/

Repeat the command several times and save the results. Compare measurements taken throughout the day. If TTFB is around 200–300 ms in the morning but regularly rises to 800–1,500 ms in the evening, the bottleneck is almost certainly on the server side.

Next, examine the web server error log.

For Nginx, run:

tail -100 /var/log/nginx/error.log

If you regularly see messages such as upstream timed out, connect() failed, or PHP-FPM connection errors, the server is already operating close to its limits. At the same time, review the PHP-FPM logs to determine whether worker processes are becoming exhausted.

On your own VPS, you can inspect the service log with:

journalctl -u php-fpm -n 100

or on Ubuntu:

journalctl -u php8.3-fpm -n 100

Pay particular attention to messages such as server reached pm.max_children, Allowed memory size exhausted, or repeated PHP process crashes. These indicate that new requests are waiting for available workers, causing noticeable delays before users begin seeing 503 errors.

The next step is to examine the database. Review the MySQL or MariaDB slow query log and check whether slow queries become significantly more frequent during peak traffic. If the log remains almost empty in the morning but fills rapidly in the evening, your current hosting plan is reaching its limits, or the application requires optimisation.

Now assess the server itself.

In one terminal, run:

top

In a second terminal:

vmstat 1

In a third:

iostat -x 1

While the site is performing poorly, monitor all of these metrics together. If CPU utilisation remains consistently high, available memory is exhausted, swap starts being used, and iowait continues to increase, the server can no longer process requests efficiently. If traffic is still growing, performance will continue to deteriorate.

If your website is hosted on a CloudLinux shared hosting platform, review the resource usage statistics provided in your control panel. Check whether the account is regularly hitting CPU, RAM, Entry Processes, NPROC or I/O limits. Frequent limit violations are a strong indication that the website has outgrown its current hosting plan.

You can consider the assessment complete once you have compared TTFB throughout the day, reviewed your web server, PHP-FPM and database logs, checked CPU utilisation, memory usage, swap activity and iowait, and confirmed whether CloudLinux or PHP-FPM limits are being reached. If most of these indicators deteriorate consistently during peak traffic periods, shared hosting is no longer sufficient for your project. At that point, migrating to a VPS is far preferable to waiting until persistent 503 errors and slow performance begin affecting both users and search engine crawlers.

How to Estimate Your Website's Real CPU and RAM Requirements

Many people begin choosing a VPS by looking for a universal sizing formula. A common example is trying to calculate how many CPU cores are needed for every 1,000 daily visitors. In practice, this approach rarely works. Two websites with identical traffic can generate completely different workloads. One may serve mostly cached static pages, while another processes product searches, catalogue filters, dynamic pricing, shipping API requests, shopping carts and continuous database writes on every page load. The visitor count may be identical, but CPU and memory usage can differ dramatically.

The first step is to ignore average daily traffic and identify your busiest period instead. Open your analytics platform and find the hour with the highest number of active visitors. That is the workload your server must be able to handle. Infrastructure should always be sized for peak demand rather than the daily average.

Next, determine which parts of the website generate the highest load. For an online shop, review category pages, product filters, product pages, search, the shopping basket, checkout, customer accounts, product imports and integrations with third-party services. If you use WordPress or another CMS, also measure the responsiveness of the administration panel. Quite often, the biggest source of load is not website visitors at all but scheduled cron jobs, backups, data imports or image processing tasks running in the background.

The next step is to measure response times for your most demanding pages.

For a quick test, run:

curl -o /dev/null -s -w \ "TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" \ https://example.com/category/

Repeat the same test for search results, product pages, the shopping basket, checkout and any other sections that rely heavily on database queries. If these pages become significantly slower during peak traffic while simpler pages remain responsive, increasing server resources may deliver better results than optimising individual application components.

Now check how many PHP workers are running simultaneously.

Run either:

ps -ylC php-fpm --sort:rss

or

ps aux | grep php-fpm

If a large number of PHP-FPM workers are active during peak periods and new requests are waiting for available workers, your current CPU or memory allocation is already becoming a limiting factor.

The next step is to determine how much memory each PHP worker consumes. In the output of the ps command, look at the RSS column. For example, if each worker uses around 180 MB of memory and 20 workers are active simultaneously, PHP-FPM alone requires approximately 3.5 to 4 GB of RAM. You must then add memory for MySQL or MariaDB, Redis, the web server, the operating system and background services. This is why a VPS with only 4 GB of RAM can begin using swap much sooner than expected.

Next, evaluate your database size and the performance of expensive queries.

Connect to MySQL or MariaDB and run:

SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024,2) AS size_mb FROM information_schema.tables GROUP BY table_schema ORDER BY size_mb DESC;

Then examine the slow query log to identify which queries take the longest to complete. If the log fills rapidly during busy periods, the bottleneck may not simply be insufficient CPU resources. Database performance may also be contributing to the slowdown.

Do not overlook background tasks. Many production systems experience unexpected performance spikes because of scheduled jobs rather than user activity. Backups, catalogue imports, image generation, bulk email delivery and cron jobs can increase CPU utilisation several times over, even when visitor numbers remain relatively low.

Finally, compare all of the information you have collected. If TTFB increases only during peak hours, many PHP workers are active simultaneously, memory is almost fully utilised, swap begins to appear, the slow query log consistently records expensive queries and resource-intensive operations noticeably slow the website, the current server no longer has enough capacity for the workload.

Your assessment is complete once you have identified the busiest traffic period, measured TTFB for the most demanding pages, counted simultaneous PHP-FPM workers, calculated memory usage per process, reviewed database size, analysed the slow query log and confirmed that background tasks are not creating unexpected load spikes. Only after completing this analysis can you select an appropriate VPS configuration based on the website's actual workload rather than an arbitrary estimate based on daily visitor numbers.

How to Size RAM for a VPS Running PHP-FPM, MySQL/MariaDB and Redis

After migrating to a VPS, many administrators focus only on the amount of RAM included in the plan. A server with 4 GB or 8 GB of memory looks perfectly adequate on paper. A few days later, swap starts being used, page load times increase, the administration panel becomes sluggish, and product imports or backups take much longer than expected. Meanwhile, CPU utilisation may still be sitting at only 20–30%. In most cases, the cause is straightforward: memory was allocated for the website itself, while every other service running alongside it was overlooked.

Start by checking current memory usage.

Run:

free -h

Don't look only at the amount of free memory. Pay close attention to the Swap line as well. If swap is already being used during normal operation, the server is running short of RAM. Even a few hundred megabytes of swap usage usually indicates that physical memory is periodically being exhausted.

Next, identify which processes are consuming the most memory.

Run:

ps aux --sort=-%mem

or:

top

The processes at the top of the list are typically PHP-FPM, MySQL or MariaDB, Redis, your control panel and other system services. These are responsible for most of the server's memory consumption. If one process is unexpectedly using several gigabytes of RAM, investigate the cause before simply upgrading the VPS.

The next step is to estimate the maximum amount of memory PHP-FPM can consume. Open the PHP-FPM pool configuration and locate the following parameter:

pm.max_children

For example:

pm.max_children = 40

Now determine how much memory each PHP worker actually uses.

Run:

ps -ylC php-fpm --sort=rss

Check several running workers and calculate the average RSS value. If each PHP process uses roughly 120 MB of memory and up to 40 workers can run simultaneously, PHP-FPM alone can consume almost 4.8 GB of RAM.

That does not mean the server only needs 5 GB of memory.

The next step is to account for every other service running on the system.

Check MySQL or MariaDB memory usage:

ps -C mysqld -o pid,rss,cmd

If Redis is installed, check its current memory consumption:

redis-cli INFO memory

Pay particular attention to:

used_memory_human

Don't forget the services that are often ignored during capacity planning. Your web server, control panel, mail services, antivirus software, scheduled backups, cron jobs and the operating system itself all require memory. During a backup or a large catalogue import, total RAM usage can easily increase by several gigabytes.

A simple calculation makes it much easier to estimate how much memory your VPS actually requires.

For example:

PHP-FPM — up to 4.8 GB

MySQL or MariaDB — approximately 1.5 GB

Redis — around 500 MB

Nginx — roughly 200 MB

Control panel and system services — about 800 MB

Safety margin for cron jobs, backups and peak traffic — at least 1–2 GB

With a workload like this, a VPS with 4 GB of RAM will inevitably begin using swap, while an 8 GB server is much closer to the real requirements of the application.

Once you've completed your calculations, verify everything during your busiest traffic period.

Run the following commands simultaneously:

free -h

top

vmstat 1

Watch several metrics at the same time. If available memory falls close to zero, swap usage continues to increase, and the si and so columns in vmstat regularly show non-zero values, the operating system is actively moving memory pages between RAM and disk. This is usually the point where TTFB rises sharply, the administration panel becomes noticeably slower, and users begin experiencing inconsistent performance even though CPU utilisation appears relatively modest.

You can consider the assessment complete once you have determined the maximum number of PHP-FPM workers, measured memory consumption per worker, calculated PHP's potential peak memory usage, evaluated RAM usage by MySQL or MariaDB, Redis and system services, reviewed the output of free -h, top and ps aux --sort=-%mem, and confirmed that the server is not relying on swap during peak traffic. Only then can you choose a VPS with enough memory not only for today's workload but also for future growth without running into memory bottlenecks.

Choosing Storage for a Website with a Growing Database

Many administrators only start thinking about storage performance when disk space is almost exhausted. In reality, the warning signs appear much earlier. The product catalogue grows, the database expands, search results become slower, product filters take longer to respond, the administration panel feels increasingly sluggish, and a backup that once completed in a few minutes now takes half an hour or more. Meanwhile, CPU utilisation may still be only 20–30%, and plenty of RAM remains available. In many cases, the real bottleneck is storage performance.

The first step when selecting a VPS is to stop judging storage by capacity alone. For dynamic applications such as WordPress, WooCommerce, Joomla, Moodle, CRM platforms and similar systems, the ability to process large numbers of small read and write operations is far more important than total disk space. That is why NVMe storage should be the default choice. Its high random I/O performance has a much greater impact on a growing database than having hundreds of extra gigabytes of unused storage.

Begin by confirming that storage is actually causing the slowdown.

During normal website activity, run:

iostat -x 1

Watch several metrics together. If await steadily increases, svctm rises, and util remains close to 100% for extended periods, the storage device is no longer processing requests quickly enough. At that point, the CPU may spend much of its time waiting for I/O operations to complete instead of performing useful work.

The next step is to examine the MySQL or MariaDB slow query log. If queries that previously completed quickly now begin appearing regularly, resist the temptation to immediately add indexes or rewrite SQL statements. First, compare the timing of slow queries with storage activity. Quite often, the database engine itself is performing normally but is simply waiting for disk reads or writes to finish.

Now run a basic storage performance test.

For example:

fio --name=randrw \ --rw=randrw \ --bs=4k \ --size=1G \ --numjobs=4 \ --runtime=60 \ --time_based

This is not a substitute for comprehensive benchmarking, but it provides a quick indication of random read and write performance. These are precisely the operations that dominate workloads on most CMS platforms, e-commerce applications and database-driven websites.

Next, evaluate the website from the user's perspective. Open product categories, perform searches, apply several filters, sign in to the administration panel, save changes to a product and start a backup. If iowait rises during these operations while page response times increase significantly, storage has become the limiting factor.

Don't overlook backup duration. For many production websites, backups are the first task to reveal declining storage performance. If a backup that completed in five minutes a few months ago now consistently requires forty minutes despite only moderate data growth, storage performance should be investigated before users begin noticing slowdowns.

It is also worth checking the size of your database and how quickly it is growing. If the catalogue expands daily, new images are uploaded continuously, orders accumulate and CRM records increase over time, storage demand will continue to rise. In this situation, the performance headroom provided by NVMe storage is far more valuable than choosing a lower-cost VPS with a conventional SSD.

Finally, repeat your checks during the busiest period of the day. At the same time, monitor:

iostat -x 1

top

and the database slow query log.

If opening product categories, running searches, applying filters or creating backups causes iowait to increase significantly, the CPU spends time waiting for disk operations, and the slow query log fills rapidly, the limiting factor is no longer the CMS or the database engine itself. The underlying issue is storage performance.

You can consider the assessment complete once you have analysed disk latency with iostat -x 1, reviewed the MySQL or MariaDB slow query log, run a fio benchmark, compared the performance of product catalogues, search, the administration panel and backups, and confirmed that the storage subsystem is not responsible for rising iowait during peak traffic. Only after completing this analysis should you choose a VPS based on storage performance rather than disk capacity alone.

How to Check Whether Your Network Can Handle Growing Traffic

After migrating to a VPS, it is common to find that pages are generated quickly, CPU utilisation remains low and the database performs well, yet users still complain that the website feels slow. The homepage loads almost instantly, but images appear gradually, PDF documents download much more slowly than expected, the customer account takes a long time to load JavaScript, and performance drops noticeably during marketing campaigns. The immediate assumption is often that PHP or MySQL is responsible. In reality, the server is generating pages quickly but is unable to deliver them to visitors fast enough.

The first step is to identify which resources consume most of the page load time. Open the website in your browser, press F12 to launch Developer Tools, switch to the Network tab and reload the page with the browser cache disabled. Sort requests by size and loading time. If the HTML document is delivered within a few hundred milliseconds while images, JavaScript, CSS, PDF files or other static assets account for most of the loading time, the bottleneck is no longer PHP. It is the delivery layer.

Next, check the total page size. If a single page transfers 15–30 MB of data, no VPS will deliver an instant experience when hundreds of visitors arrive simultaneously. This is especially common on e-commerce websites where pages include dozens of high-resolution product images, embedded videos, PDF catalogues and multiple JavaScript libraries.

The next step is to verify that the server is using modern transport protocols. Start by checking whether HTTP/2 is enabled.

Run:

curl -I --http2 https://example.com

If the server responds over HTTP/2, browsers can download multiple assets concurrently through a single connection. If the website still relies on HTTP/1.1, pages containing large numbers of CSS files, JavaScript bundles and images will load less efficiently.

Now verify that compression is enabled.

For example:

curl -I -H "Accept-Encoding: gzip, br" https://example.com

The response should include headers indicating that gzip or Brotli compression is active. Without compression, HTML, CSS and JavaScript files become significantly larger than necessary, increasing transfer times and bandwidth consumption.

The next step is to measure download performance for large files.

For example:

curl -o /dev/null -s -w \ "Speed: %{speed_download} bytes/sec\nTime: %{time_total}\n" \ https://example.com/files/catalog.pdf

Repeat the test using several large images, archives or downloadable documents. If download speeds are consistently much lower than expected, investigate the server's network configuration or any bandwidth limitations imposed by the hosting plan.

If the VPS is already in production, inspect the network interface under real traffic.

For live traffic monitoring, run:

iftop

or

vnstat -l

If your hosting control panel provides network statistics, compare current traffic levels with the available bandwidth of the network port during peak usage periods.

If your audience is distributed across multiple countries, evaluate whether a Content Delivery Network (CDN) would be beneficial. This becomes particularly important for websites serving large numbers of images, downloadable files, videos or other static assets. Delivering this content through a CDN reduces the load on the origin server while improving download speeds for visitors located far from the data centre.

The final step is to repeat these checks during your busiest traffic period. Monitor the Network tab in your browser, repeat the curl -w download tests, observe live traffic with iftop or vnstat, and compare the delivery time of the HTML document with that of images, CSS, JavaScript and large downloadable files. If the server generates pages quickly but static content is transferred much more slowly, neither PHP nor the database is the bottleneck. The limiting factor is the network layer, the volume of transferred data or the content delivery infrastructure.

You can consider the assessment complete once you have measured total page size, evaluated the download speed of static assets, confirmed that HTTP/2 and compression are enabled, tested large file transfers, monitored network utilisation and verified that the available bandwidth remains sufficient during peak traffic. Only after completing this analysis can you decide whether the solution is a faster network port, a CDN, or reducing the amount of data each page delivers.

Choosing a VDS KVM Linux Server for a Website with Growing Traffic

Once you have analysed CPU utilisation, memory usage, storage performance and network throughput, it usually becomes clear that the decision to move to a VPS is not driven by visitor numbers alone but by how the application behaves under load. One website may comfortably handle several thousand visits per day, while another begins struggling with far less traffic because of complex SQL queries, large numbers of PHP workers, intensive search operations, product filtering, API requests, background jobs or a steadily growing database. That is why you should choose a VDS KVM Linux server based on real peak workloads rather than average daily traffic.

When comparing VPS plans, don't focus solely on the number of virtual CPU cores or the amount of RAM. It is far more useful to understand how your application consumes resources today and how quickly those requirements are growing. If your database expands by several gigabytes every month, the number of simultaneous PHP-FPM workers continues to increase, Redis consumes progressively more memory and backups take longer to complete, your server should provide enough capacity not only for the current workload but also for future growth.

Before selecting a VPS, perform a short assessment.

After completing this assessment, perform several practical checks. Measure TTFB during peak traffic, review your web server and database logs, confirm that PHP-FPM is not reaching the pm.max_children limit, verify that swap is not being used continuously, monitor iowait while the product catalogue and backups are running, and ensure that the network interface is not slowing the delivery of static assets. If any one of these components is already operating close to its limits, the next server should be selected with future growth in mind rather than today's workload alone.

Before making the final decision, ask yourself one more question. If traffic doubles over the next six months, the product catalogue grows substantially, the database expands by tens of gigabytes, new integrations are added, additional cron jobs are introduced and the number of concurrent users increases, will the server still cope without requiring another migration? If the answer is no, the chosen configuration is likely to become inadequate much sooner than expected.

A well-sized VDS KVM Linux server does not automatically make a website faster. Its real purpose is to provide sufficient CPU capacity, memory, NVMe storage performance, MySQL or MariaDB throughput, Redis capacity, PHP-FPM headroom and network bandwidth so that the website continues to operate reliably as traffic grows. That is why a VPS should be chosen based on how long it will support the project's development, not simply because it offers the lowest monthly price. A properly sized platform allows the application to grow without constant resource shortages, emergency optimisation or another migration only a few months later.