How to Load Test Your VPS Before a Launch or Sale

Your WordPress site loads fine every time you check it. Then the launch email goes out, or a flash sale starts, and the server chokes right when it matters most. If nobody tested it under real concurrent load first, you find out live, in front of paying customers. Here's how to load test a Getwebup VPS properly before you need it to hold up — and what to fix when it doesn't.

Symptom: fine alone, falls over under real traffic

This is the pattern almost every "why did my site go down during the sale" ticket has in common: the site was tested by one person, in one browser tab, and it looked perfect. Page loaded in under a second, checkout worked, everything felt snappy. Nobody ever hit it with 50 or 200 people at once before launch day did it for them.

A single visitor tells you nothing about how the server behaves under concurrency. PHP-FPM, MySQL, and Nginx all have hard caps on how many requests they'll handle at the same time — caps that are invisible until you cross them, at which point new visitors start getting 502s, 504s, or a site that just hangs.

Cause: PHP-FPM, MySQL, and Nginx are all capped lower than you think

Three defaults quietly limit how much concurrent traffic a VPS can absorb:

• PHP-FPM pm.max_children — the number of PHP processes that can run at once. On a stock 2GB VPS this is often left at a default like 5–10, which is nowhere near enough for a traffic spike.
• MySQL max_connections — defaults to 151 on most installs. Fine for normal browsing, tight once WooCommerce, wp-cron, and a few plugins are all opening connections during a sale.
• Nginx worker_connections — caps how many simultaneous connections each worker process accepts. Left at a low default, it queues or drops connections before PHP even gets involved.

Any one of these maxing out looks the same from the outside: slow pages, then timeouts, then a server that appears "down" even though it's technically still running.

Fix: run a real load test before you need one

1. Test against a clone, not live production

Load testing your production site while real customers are on it will make the outage happen early instead of preventing it. Clone the site to a staging subdomain first — cPanel's Clone/Stage tool or a WP Staging plugin both work — and point your load tests there.

2. Get a baseline with Apache Bench

ab ships with the Apache utilities and is the fastest way to get a first number. From your local machine or a separate VPS (never from the same server you're testing):

ab -n 500 -c 50 https://staging.yourdomain.com/

That sends 500 requests total, 50 of them concurrently. Watch the "Requests per second" and "Failed requests" lines in the output — a rising failure count as concurrency increases is your first real signal.

3. Get more realistic with wrk

wrk handles higher concurrency better and reports latency percentiles, which matter more than averages:

wrk -t4 -c100 -d30s --latency https://staging.yourdomain.com/

This runs 4 threads holding 100 connections open for 30 seconds. The --latency flag adds a percentile breakdown so you can see what your slowest 1% of visitors actually experience, not just the average.

4. Script a real checkout flow with k6 (for stores)

If the site sells anything, test the checkout path specifically — that's where database writes pile up, not the homepage. k6's own quickstart docs show how to write a small test file that visits your shop page, waits a second, then visits a product page. Point that script at 50 virtual users for a minute with vus: 50 and duration: '1m' in the options block, then run it with:

k6 run cart-flow-test.js

It's more setup than ab, but it's the only way to catch problems that only show up on database-heavy pages like add-to-cart and checkout.

5. Read the results correctly

6. Fix what breaks, one layer at a time

Don't tune everything at once — you won't know what actually helped. Work from the front of the stack back:

1. Nginx first. Check worker_connections in nginx.conf and raise it if it's under a few thousand. This is the cheapest fix and rules out the most obvious bottleneck.
2. PHP-FPM second. A rough starting formula: pm.max_children = (available RAM in MB) / (average PHP process size in MB). Check actual process size with ps -ylC php-fpm --sort:rss — WordPress with WooCommerce commonly runs 40–80MB per process, so a 4GB VPS might reasonably support 30–40 children, not the default 5.
3. MySQL third. Check the current cap and connection usage:

   SHOW VARIABLES LIKE 'max_connections';
   SHOW STATUS LIKE 'Threads_connected';

   Raise max_connections in my.cnf only after confirming you're actually hitting the ceiling — bumping it blindly just moves the failure to RAM exhaustion instead.
4. Caching last. Once the raw ceilings are sane, a page cache (LiteSpeed Cache, or Redis for the object cache) does more for real-world load than any further tuning, because it stops most requests from touching PHP or MySQL at all.

Re-run the same wrk command after each change so you can see which fix actually moved the number.

Prevention: make load testing a launch-checklist item, not a post-mortem

• Test at 2–3x your expected peak concurrency, not your average traffic — sales and launches spike far above normal browsing.
• Re-test after any theme, plugin, or PHP version change. A single new plugin with an unoptimized query can undo all the tuning above.
• Watch the server live during the actual event with a lightweight monitor (Netdata is enough for most sites) so you catch a problem while it's still a warning, not an outage.
• For anything genuinely high-traffic — a product drop, a press mention — consider a Cloudflare rate limit or waiting-room rule as a safety net, not a replacement for proper server sizing.

None of this needs to be elaborate. Even a single ab run against a staging clone the week before a launch will surface the obvious ceilings — and that's usually enough to turn a launch-day outage into a non-event.