Last reviewed: 29 August 2026.
To load-test your store before Diwali, model real customer journeys and define pass criteria before generating traffic. According to Grafana k6, example thresholds can require less than 1% request errors and 95% of responses below 200ms. Treat those figures as syntax examples; your store needs thresholds based on its own baseline and risk.
A useful load test answers a decision: how much traffic can the current stack handle before checkout, search or another critical path violates the limit you set in advance?
What should you prepare before running the test?
Clone a representative environment, refresh data safely, and make sure the test will not trigger real payments, emails, SMS messages, fulfilment or anti-fraud actions. Confirm that monitoring covers the web tier, application runtime, database, cache, storage and relevant external dependencies. Without those measurements, a failed test tells you that users were slow but not why.
Also verify the software baseline. WooCommerce's server recommendations currently document WooCommerce 10.8 and later alongside WordPress 6.9 or greater, PHP 8.3 or greater, MySQL 8.0 or greater or MariaDB 10.6 or greater, and a WordPress memory limit of 256 MB or greater. Compatibility does not prove capacity, but an unsupported baseline makes performance results harder to act on.
How do you turn customer behaviour into a load model?
- List the important journeys: browse, search, login, cart update, checkout and account actions.
- Estimate their relative mix from analytics or server logs rather than inventing equal traffic.
- Create realistic test data and a cache state that resembles production.
- Ramp traffic gradually so you can see the first saturation point instead of only the final failure.
- Record infrastructure metrics and application traces throughout the same timeline.
- Rerun the identical scenario after each material change.
The model should include think time and variation where the tool allows it. Real shoppers do not submit every request at the same instant, and static assets may be cached differently from dynamic checkout actions. Your aim is not to manufacture a dramatic requests-per-second number; it is to create a repeatable workload that exercises the expensive paths closely enough to guide an infrastructure decision.
Which thresholds should you define?
Grafana's k6 documentation explains thresholds as pass/fail criteria. Its examples include less than 1% request errors, 95% below 200ms, 99% below 400ms and a specific endpoint within 300ms. Use that pattern to define store-specific limits for critical journeys, then keep the criteria unchanged while comparing infrastructure or application changes.
Averages are rarely sufficient. A checkout system can look healthy on average while a tail of slow requests drives abandonment and support tickets. Pair latency thresholds with error rate and business-level checks such as whether cart state survives, orders are created correctly in the isolated test environment, and the application remains responsive after the burst ends.
| Test evidence | Question it answers | Typical next step |
|---|---|---|
| CPU saturation | Is compute the first limit? | Profile hot code or test more compute |
| Database wait growth | Is persistence slowing the journey? | Inspect queries, locks, cache and I/O |
| Error spike with concurrency | Which pool or dependency is exhausted? | Trace the failing route and tune its limit |
| Healthy origin, slow user path | Is the bottleneck outside the host? | Inspect DNS, proxy, CDN and network timing |
How do you diagnose the first bottleneck?
Mark the time when the user-facing threshold first fails, then inspect the same interval across server and application telemetry. If CPU is saturated, verify whether useful application work is consuming it.
When memory is pressured, inspect working set, caching and process limits. Storage latency should lead you to the reads or writes causing it. Database slowdown should lead to the expensive queries before you add web-tier resources.
Third-party services belong in the diagnosis. Payment gateways, search services, fraud checks, shipping calculators and marketing APIs can become the slowest part of a checkout path. Use explicit client timeouts and error handling, and decide which functions can degrade gracefully. A bigger server cannot remove latency from an external dependency that the application waits for synchronously.
How should you load-test your store without damaging production?
Prefer an isolated environment that mirrors production closely enough to expose the same bottlenecks without creating real customer effects. Disable or sandbox payment, email, messaging, shipping and fraud integrations where test traffic could create charges or operational work. Coordinate with the hosting provider if the test could resemble abusive traffic or trigger automated protection. Keep the test source addresses and time window documented so logs can be separated from real users.
If a limited production validation is unavoidable, constrain it to a reviewed scope and stop condition. Do not use a surprise peak as a test method. Production data, customer sessions and third-party quotas can turn a technically valid load generator into a business incident. The purpose is to learn system limits deliberately, with monitoring and an owner ready to stop the run when the defined boundary is reached.
What should you do after each run?
- Save the test script, data assumptions, software version and infrastructure configuration.
- Save the dashboard or metric export for the failure interval.
- Change one important variable at a time where possible.
- Repeat the same workload to compare rather than changing the target mid-experiment.
- Record the result and the rollback condition for the change.
Before testing any risky server change, follow WooCommerce's advice to back up the site and files. For a fuller recovery design, use the backup and rollback strategy. Keep a short change log with the reason, result and rollback point so the next run remains comparable. For the campaign-level decision, return to the festive WooCommerce capacity plan.
How should test results become a release decision?
Convert the run into a short decision record rather than leaving the team with a dashboard screenshot. Note the workload shape, the environment, the build tested, the pass-or-fail thresholds and the first resource or dependency that became constrained. Then classify each finding as a release blocker, a capacity action or an observation to watch during the event. This keeps a visually impressive traffic number from hiding a checkout, payment or inventory failure that matters more to the business.
After a fix, rerun the same scenario before changing the test again. Comparable reruns tell you whether the remediation improved the original bottleneck or merely moved it. Keep the final test configuration with the release notes so on-call staff know what “expected” looked like before campaign traffic arrived. A useful load test ends with named owners, explicit remediation and a repeatable baseline, not just a claim that the store survived a synthetic spike.
Frequently asked questions
What should I load-test first?
Start with the customer journeys that create revenue or operational risk: search, product browsing, login, cart changes and checkout. A homepage-only test can miss the expensive dynamic paths.
Should my threshold match Grafana's example numbers?
No. Grafana's numbers are examples that demonstrate threshold syntax. Set your own pass criteria from production baselines, user expectations and business risk.
What if the test fails because a third-party service is slow?
Keep that result. It identifies a real dependency risk. Decide whether to add timeouts, graceful degradation, caching, queueing or a provider escalation rather than hiding the dependency from the test.
When is the test good enough?
The test is useful when it reproduces the important workload, has explicit pass criteria, exposes the first limiting component, and can be repeated after a change. Stop chasing an arbitrary peak once you have enough evidence to decide what to tune, resize or redesign and enough headroom to meet the campaign scenario you actually expect.