Load testing a website before launch
A load test answers two questions: how many visitors a site can handle on the chosen server and what breaks first. It is run on your own server and only there: the load generator is a separate machine, the host has been notified and external services are replaced with stubs. Here are the numbers to watch, the tools that produce them and how to use them to choose a plan.
A site that opens quickly for its developer can stop responding when a hundred people arrive at once: it runs out of PHP processes, database connections or memory. Finding this out on the day of an advertising campaign costs far more than finding it out a week earlier. A load test reproduces a stream of visitors on your server and shows where the limit is and how much headroom you have left.
What to measure
The result of a test is not a single number but a set of metrics that are read together:
- RPS (requests per second) is how many requests the server handles. On its own, RPS says little: a server can answer a thousand requests per second while every response takes five seconds.
- Response time percentiles. p95 means that 95% of requests completed within that time, p99 means 99%. An average hides slow responses: if 90 requests took 100 ms and 10 took 3 seconds, the average of about 400 ms looks decent, even though every tenth visitor waits three seconds.
- Error rate covers 5xx responses, dropped connections and timeouts. Under load, errors usually appear before response times grow noticeably.
- Server resources: CPU load, free memory and swap, disk wait (iowait) and the number of database connections. These are collected on the server itself during the test; otherwise you cannot tell what the site ran into.
Set the goal in advance and in the same units, for example: "at 50 requests per second, p95 for the home page and the catalog is under 500 ms and errors stay below 1%". Without a goal, a test turns into a pile of charts that cannot support any decision.
Types of tests
- Smoke test: a few virtual users for about a minute. It confirms that the scenario is written correctly and gives a baseline response time without load.
- Load test: the expected peak traffic for 15–30 minutes. It shows whether the server copes with the planned load.
- Stress test: the load is raised in steps until errors or response times climb. It reveals the limit and how the site behaves beyond it: whether it returns an error quickly or hangs.
- Soak test: moderate load for several hours. It finds memory leaks, logs and disks filling up, and connections piling up.
The scenario should resemble real visitors: a mix of pages (home, catalog, product page, search), pauses between actions, and some users who are logged in or have items in the cart. A test that requests the same cached page a thousand times per second measures the cache, not the site.
Tools
All four programs below are free and run from the command line. The first two suit scenarios with several pages; the last two are for a quick check of a single URL.
- k6: scenarios are written in JavaScript, and results are printed straight away with percentiles. You can set thresholds in the scenario: according to the k6 documentation, conditions such as
http_req_failed: ['rate<0.01']andhttp_req_duration: ['p(95)<200']are checked at the end of the test, and if one fails, k6 exits with a non-zero code. That makes k6 easy to add to CI: a build that slows the site down will not pass. - Apache JMeter: scenarios are assembled in a graphical interface, with forms, authentication, response parsing and data from CSV files. The test itself should be run in command-line mode with
jmeter -n -t test.jmx -l test.jtl, because the GUI mode consumes the generator's resources and skews the results. - wrk is a multithreaded generator that can put heavy load on a single URL from one machine. For example,
wrk -t4 -c100 -d60s --latency https://example.com/runs 4 threads with 100 connections for one minute and reports the latency distribution. More complex scenarios are written in Lua. - ab (ApacheBench) is the simplest option and is often already installed together with Apache. Its documentation states plainly that ab does not fully implement HTTP/1.x and that under high load it may measure its own speed rather than the server's. Keep-alive is off by default and is enabled with the
-kflag. It is fine for a quick check but not for deciding on a plan.
How to test without disturbing anyone
A load test creates the same stream of requests as a rush of visitors, so it may only be run on a server you control and in line with the rules of the platform it runs on.
- Only your own server and your own domain. Putting load on other people's sites and APIs without the owner's written consent is unacceptable, even "just for a minute". If your site calls a payment gateway, a delivery service or an external API, replace them with stubs or with those services' test environments for the duration of the test.
- Notify your host. The provider's DDoS protection may mistake the test for an attack and block the generator's address, and some hosts' rules require such tests to be agreed in advance. For example, the AWS policy allows stress tests of your own prepared endpoints but prohibits DDoS simulations. A short message to support with the date, time, addresses and expected volume settles the matter. How hosts organise their protection is explained in the article DDoS protection: what hosting providers actually give you.
- Not on shared hosting. On a shared server, the test will slow down your neighbours, and the result will depend on them. Test on a VPS or a dedicated server where the resources are reserved for you.
- Run the generator on a separate machine. If it runs on the same server, it takes CPU away from the site. A VPS with hourly billing works well as a generator: you create it for the test and delete it afterwards. According to the accsly.io catalog as of November 2026, hourly billing is explicitly stated by 173 of 2,247 VPS hosts, and the plans are collected on the page VPS with hourly billing.
- Keep traffic in mind. An hour of testing can push hundreds of gigabytes. If the plan has a traffic cap or the link is shared with neighbours, the excess is billed or the speed is reduced; more on this in the article Bandwidth and traffic: what 1 Gbps and unlimited really mean.
- CDN and protection in front of the site. If the domain is connected to a CDN, a test through it measures the CDN and may hit its limits. Test the origin server directly by its address, and agree any load through the CDN with the CDN provider.
How to read the results and choose a plan
As the load increases step by step, RPS first grows along with it while response time barely changes. Then comes the saturation point: RPS stops growing, p95 rises sharply and errors appear. Your working load should stay well below this point, because you need headroom for spikes, background jobs and audience growth. A handy rule of thumb is for the expected peak to take no more than half of the limit you found.
Next, look at what the server ran into at the saturation point:
- CPU at 100%: you need more cores, or a higher clock speed if the bottleneck is a single thread; plans with clock speeds from 4 GHz are collected on the page VPS with a high CPU clock speed;
- memory ran out and the server started swapping: you need more memory or fewer PHP-FPM processes and workers; sizing guidelines are in the article How much RAM and how many cores a website needs;
- high iowait: the disk cannot keep up, usually because of the database; NVMe and indexes help, and the comparison is in the article NVMe or SSD: does it matter for a website;
- resources are free but errors occur: you have hit a configuration limit, such as the database connection limit, the number of web server workers or open files.
Before buying, it is worth repeating the test on the exact plan you intend to take: CPUs and disks differ between hosts more than the numbers in the description suggest. The easiest way is with hourly billing or during a trial period, as described in the article How to test VPS ping and speed before you pay. After launch, the same metrics (response time, errors, resource usage) move into monitoring, so that growing load becomes visible before the site starts returning errors.