Define the trading question before generating traffic
A Magento load test should answer a business question: can the store support an expected promotion, does checkout remain reliable during catalogue activity, or where does a known workload begin to degrade? “How many users can it handle?” is too vague unless the user behaviour, arrival pattern and acceptable outcomes are defined.
Midoriweb would begin with the planned event or observed bottleneck, then design scenarios that represent the relevant journeys. Browsing cached product pages creates different work from searching, signing in, changing carts or completing orders. A test that repeatedly fetches the homepage can produce reassuring numbers while leaving the expensive paths untested.
Our Performance Investigation explains the available scopes. Load generation should be explicitly agreed within the work, including environment, limits and external dependencies. It is not something to run unannounced against a live shop or its providers.
Build scenarios from representative journeys
Use existing traffic and operational knowledge where available. Identify the mix of landing pages, categories, product views, searches and cart actions that matters for the event. Record which requests are expected to be cacheable and which involve customer-specific processing.
Include realistic data variety. Repeating the same product and query may produce unusually favourable cache behaviour. At the other extreme, generating entirely random requests can create a workload unlike actual customers. The test should explain its assumptions so results can be interpreted rather than treated as a universal capacity rating.
Separate scenarios when their outcomes matter independently. Search degradation should not be hidden inside an average dominated by fast page views. Likewise, a small number of failing checkout operations can be commercially important even when total request throughput remains high.
Choose an environment and protect external systems
A representative staging environment is often the right place to begin, but document differences from production: catalogue size, data shape, infrastructure, caching, network routes and connected services. A smaller environment can help compare changes without proving production capacity directly.
Payment, email, shipping, ERP and warehouse integrations need explicit handling. Use supported test services or controlled substitutes as appropriate, and state what those substitutes cannot prove. Do not create real charges, dispatch instructions or customer notifications as an accidental consequence of a performance test.
Agree authorisation and limits for every system receiving generated traffic. A test of your storefront can still impose load on a third-party service. The test plan should identify those dependencies and prevent unexpected costs or operational side effects.
Establish pass criteria and stop conditions
Define acceptable response times, error rates and business outcomes before the run. Use measures appropriate to each scenario, including slower-percentile behaviour rather than relying only on averages. An average can look healthy while a meaningful share of customers waits much longer.
Tools such as k6 support scenario and threshold definitions; its threshold documentation explains how test criteria can be expressed. The values must come from the store’s requirements, not copied from a tutorial’s demonstration target.
Stop conditions are separate from pass criteria. Agree when to terminate a run because of excessive errors, resource pressure or unexpected side effects. Ensure someone can observe the application and infrastructure while traffic is generated and can act if the test behaves differently from the plan.
Worked example: a fast average can hide slow search
The following numbers are invented to explain the calculation. They are not a benchmark, a customer result or a capacity claim.
- 900 cached page requests each finish in 200 milliseconds.
- 100 search requests each finish in 4,000 milliseconds.
- The combined average is 580 milliseconds: (900 × 200 + 100 × 4,000) ÷ 1,000.
A report that highlights only the combined average can make this workload look reassuring. Every search request still takes four seconds. If the agreed search-response limit were two seconds, the search scenario would fail even though the combined average is below one second. Those limits are examples, not recommended targets for your store.
Report cached browsing and search separately, with their request counts, response-time distribution, errors and meaningful outcome checks. If the slow branch is search, use the Magento search diagnosis guide to decide which evidence to collect next. A capacity test identifies an affected journey; it does not establish the cause on its own.
Worked example: did the test deliver the planned load?
Imagine an arrival-rate scenario scheduled to start 10 journeys per second for 60 seconds: 600 starts were planned. If 120 iterations were dropped, only 480 started. A successful response report for those 480 cannot establish that the store sustained the planned rate.
For k6 arrival-rate scenarios, dropped iterations can occur when no virtual users are free to start the scheduled work. Insufficient allocation and longer journey durations are both possible explanations. Inspect the timing of the drops, actual iteration duration and generator resources before increasing traffic or blaming the application. Grafana explains the distinction in its dropped-iterations documentation.
In the report, distinguish journeys scheduled, journeys started, journeys completed and outcomes verified. One journey can contain several requests, so requests per second and journeys per second are not interchangeable. Retain failed and interrupted runs alongside successful ones.
Ramp demand and observe recovery
A gradual increase helps reveal where response and errors begin changing. A sudden spike tests a different behaviour and should be intentional. Sustained demand can expose resource growth or backlogs that a short burst misses. Choose the pattern that matches the question rather than combining every test type indiscriminately.
Record the exact scenario version and configuration. A result without its workload definition is difficult to reproduce and easy to misinterpret. Note the initial cache and data state, because those conditions can materially affect the run.
After traffic stops, observe recovery. Queues, background work and resource use should return towards the expected state. A system that responds well during a short test but leaves a growing operational backlog may not be ready for repeated campaign peaks.
Correlate customer outcomes with infrastructure evidence
Collect application timings, errors and relevant infrastructure observations over the same interval. PHP workers, database work, cache behaviour, search and external APIs can all influence the result. The objective is to identify the limiting path, not simply collect a large dashboard of unrelated metrics.
Our PHP-FPM guide, cache memory guide and database contention guide explain common diagnostic branches. Use them when the evidence points to that layer rather than assuming every slow test requires more hardware.
Also verify business responses. An HTTP success code can accompany an empty result, validation error or cached page that does not represent the intended journey. Scenario checks should confirm the meaningful outcome without storing unnecessary customer data in test reports.
Distinguish load-generator limits from application limits
The tool generating traffic has its own CPU, memory and network constraints. If it cannot sustain the planned workload, the observed arrival rate may differ from the configuration. Check what was actually generated before attributing every plateau to Magento.
Document connection behaviour, geographic assumptions and whether assets are included. A protocol-level test and a browser-based test measure different things. Neither should be presented as a complete replacement for the other: backend capacity and real browser rendering both contribute to the customer experience.
For frontend responsiveness and visual stability, combine capacity work with the Core Web Vitals assessment. A server handling requests successfully does not prove that the customer’s device can execute the resulting page efficiently.
Use the result to choose a specific improvement
A useful report states the workload tested, the observed constraint, supporting evidence and the recommended next change. It should also explain uncertainty and environmental limitations. “Passed 1,000 users” is not meaningful without the behaviour and timing represented by that number.
Change one significant factor or a clearly defined related set, then rerun the comparable scenario. This shows whether the recommendation improves the relevant outcome and whether another bottleneck becomes visible. Preserve both successful and unsuccessful results so decisions are based on evidence rather than the best-looking run. If the slowdown follows invalidation, use the cache stampede investigation guide to compare the warm state with the recovery period.
Potential actions include reducing expensive application work, improving cache use, adjusting background schedules or increasing justified capacity. The result should determine the priority. A larger server is one possible tool, not the default conclusion.
A short brief for a useful load test
Copy these prompts into your project notes. Approximate answers are useful; mark unknowns for discussion rather than inventing a traffic target.
- Trading question: what event or growth assumption are we testing?
- Customer journey: which browse, search, basket or checkout steps must remain usable?
- Workload evidence: what do recent traffic, order and promotion records tell us about volume and the mix of journeys?
- Test boundary: which environment, accounts and external services may be exercised, and who authorises it?
- Pass and stop rules: which customer outcomes matter, what signals stop the run and who can make that call?
- Decision after the test: who reviews the evidence, approves changes and agrees any repeat run?
Leave passwords, API keys and customer records out of the initial enquiry. We can agree a suitable access process after scoping.
Prepare the operational plan as well as the store
Planning a promotion or seasonal peak? Review Peak Readiness and the other Performance Investigation packages, then describe the event, expected demand and critical customer journeys. Peak Readiness is scoped by enquiry. Agree whether controlled load generation is included, the permitted environment, third-party limits and the evidence to be delivered before any test begins. Snapshot does not establish load capacity, and implementation is scoped separately.
A promotion needs monitoring, ownership and a recovery procedure alongside technical capacity. Agree who watches the event, which indicators matter and how to pause a harmful integration or roll back a release if necessary. Keep accepted orders and payment records protected during any intervention.
Midoriweb’s performance and infrastructure services can connect testing with practical readiness. Bring the expected event, current traffic evidence, critical journeys and known dependencies to the initial discussion. We can then define a test that answers a real decision rather than generates impressive but unhelpful numbers.
Load-testing questions
Can a homepage test prove checkout capacity?
No. Checkout has different state, processing and dependencies. It needs a scenario appropriate to the actual purchase journey.
Should we test production?
Only under an explicitly agreed plan with suitable limits, monitoring and side-effect controls. Begin with the safest environment capable of answering the question.
Does one passing test guarantee the next sale event?
No. Results apply to the tested workload and conditions. Changes in traffic mix, catalogue, code or external services can alter behaviour.