Load testing of a web application: how to prepare and not get false results
Load testing does not answer the question “will the site withstand a lot of visitors”, but a more useful one: what real user actions will the system perform with the agreed quality and where will it stop doing this?. Without scenarios and metrics, a test easily turns into a beautiful graph, which makes it impossible to make a technical decision.
This article contains a working procedure for preparation. It is suitable for an online store, personal account, B2B portal or API. If it is necessary not only to conduct a test, but also to correct limitations in the architecture, this is included in the work on development of high-load systems.
1. Start with the purpose of the test
The phrase “test under load” is too vague. The test must have one or more testable objectives:
- withstand the launch of advertising without degradation of the order process;
- check how the API behaves when parallel loading of data by partners;
- understand whether your personal account will withstand the reporting period;
- compare the state of the system before and after optimization;
- find the limit after which scaling or limiting some functions is required.
The goal drives all other decisions: what scenarios to include, how many virtual users to run, what metrics to consider successful, and what to do with the results.
2. Choose business scenarios, not pages.
Checking the home page alone says almost nothing about the reliability of the product. A user scenario consists of a chain of actions and dependencies. For a store, this could be searching for a product, adding it to the cart, calculating delivery, making a reservation and paying. For a B2B service - login, receiving a list, working with a document, exchange with an accounting system and notification.
For each scenario, record:
- Who performs it and how often.
- What requests and external systems are involved.
- What response time is considered acceptable.
- What is considered an error: HTTP status, timeout, invalid data, lost event.
- What happens when an external dependency is temporarily unavailable.
This is especially important for systems with queues and APIs. The load may look normal on the front end, but accumulate in background tasks and appear an hour after the test.
3. Prepare real-life data
An empty test database often gives false optimism. A query that works quickly on a hundred records may behave differently on a workspace with filters, access rights, and relationships between entities.
There is no need to copy personal data into the test circuit. It is enough to prepare anonymized or synthetic sets with a similar volume and distribution: active and archived records, popular products, a long history of operations, several user roles. Separately check competition scenarios for one resource: remaining product, recording slot, document or general limit.
4. Agree on metrics before launch
A good report goes beyond the average response rate. The average value may hide a situation in which some users are waiting too long. It's usually helpful to look at:
- percentile response time for each critical scenario;
- error rate and types of errors;
- queue processing speed and number of retries;
- CPU, memory, network and disk load;
- database status: slow queries, locks, connections, indexes;
- external dependencies and their timeouts;
- business result: whether orders were completed, whether there were duplicates or lost transactions.
It’s best to discuss targets with the product owner. The approach to such indicators in operational systems is described in Google SRE SLO Guide.
5. Do several types of tests
One “maximum” run rarely gives the full picture. For practical assessment, different modes are usually needed:
- basic test - confirms that the script runs without noticeable load;
- smooth growth - shows at what level delays and errors begin to increase;
- peak test - simulates a short surge in demand;
- long test - detects memory leaks, queue accumulation and degradation over time;
- dependency failure test - checks behavior when the external API is delayed or unavailable.
It is important to increase the load in a controlled manner and maintain the configuration of each run. Then, after the corrections, you can repeat exactly the same scenario and honestly compare the result.
6. Don't stop with a list of problems.
A test is only useful when a plan emerges from it. Each finding should have: a cause or hypothesis, an impact on the scenario, a priority, how to check after correction, and an owner of the action.
For example, a difficult query can be solved by using an index, rewriting the selection, caching, or moving the report out of the transaction loop. Synchronous integration - queuing, retries and idempotent processing. The choice depends on consistency requirements and the user journey.
In the project OfficeScanner transactions, documents, telephony, marketing channels and analytics interact. For such systems, load analysis should take into account not just one screen, but a chain of integrations and work with data by role.
Typical errors during load testing
Immediately test “to the maximum”
Without a baseline, it is impossible to understand at what point the system degrades and what has changed after correction. Start with the expected normal profile, then build up the flow.
Replace external systems without recording this fact
Mocks are useful if a third-party service cannot be loaded. But then the result refers to your outline, not the full user path. This needs to be clearly stated in the report.
Look at HTTP 200 only
The request may succeed but create a duplicate, hold a message in a queue, or return stale data. Add business outcome checks.
Conclude “microservices are needed” based on one graph
The cause could be in the database, cache, integration, or single handler code. Microservices are justified not as an automatic response to load, but when individual parts of the product need to scale and release changes independently. Read more in the material "Monolith or microservices".
Checklist before launch
- Critical scenarios and their priority are agreed with the business.
- The test data is similar to the real volume and does not contain personal data.
- Targeted delays, errors and business checks were recorded.
- Metrics of the application, database, queues, infrastructure and external dependencies are connected.
- Know where the test is running and how it will not impact users.
- There is an owner for analyzing the results and a date for re-checking after corrections.
If some of these points are not yet clear, start with highload system audit. It helps turn “performance needs to be tested” into scenarios, metrics, and a coherent work plan.
FAQ
How often should you conduct load testing?
Before expected peaks, major releases, migrations and changes in critical integrations. For important scenarios, it is useful to repeat the tests regularly to see regressions before production.
Is it possible to test production?
Sometimes limited checks are carried out in production with pre-agreed limits and monitoring. But it is safer to perform the main load experiment in a circuit close to production, so as not to risk data and users.
How to conduct load testing?
The tool is selected for the protocol and scenarios. It is more important to correctly describe the flow, data and checks than to choose a specific tool name. For example, in Grafana k6 documentation Common types of tests are described in detail.