Capacity and load testing for Magento 2

Part 5 of the Magento 2 Performance/DevOps series — know the ceiling before you hit it. This is the final post.

The campaign is not the time to discover the limit

A flash sale or a marketing campaign multiplies traffic on a schedule you know in advance. Load testing turns "we hope it holds" into "we know it holds to N requests per second." Capacity is a number, and the only way to get the number is to push the system until something saturates — in a staging environment, not production.

Designing a useful test

A realistic test mimics behavior, not just hits:

• Mix of routes. Categor(ies), product, search, add-to-cart, and checkout in proportions that match analytics. A test that only hammers the homepage misses the expensive paths.
• Ramp, not a wall. Increase load gradually to find the knee where latency spikes, rather than starting at max and learning only that it failed.
• A representative dataset. A staging catalog of ten products behaves nothing like one with a hundred thousand. Seed realistically (a Govard env makes this repeatable).

Reading the saturation signals

Watch the layers as load rises:

concurrency ↑  →  response time flat  →  CPU steady        (headroom)
concurrency ↑  →  response time climbs →  DB CPU pinned     (DB bottleneck)
concurrency ↑  →  errors appear       →  PHP workers exhausted (app bottleneck)

The first resource to saturate is your constraint. Usually it is the database connection pool, PHP worker count, or cache throughput — each points to a different fix (connection limits, php-fpm children, or a warmer cache).

Sizing capacity

From the test you get a sustained throughput and a saturation point. Size the production tier with headroom above the campaign's expected peak, plus a buffer for the unexpected. The buffer is cheaper than a downed store during the one event that matters most.

Pitfalls

• Testing only the homepage. The checkout is where concurrency hurts; omit it and you learn nothing useful.
• Load testing production. You will either skew results or take the store down during the test. Use staging.
• Ignoring the knee. Reporting "handled 5000 RPS" while latency tripled past 2000 hides the real usable capacity.
• One-off test, never repeated. Capacity drifts as the catalog and code change; make load testing a periodic gate before major campaigns.

Closing the series

This Performance/DevOps arc moved from diagnosis (profiling) to prevention (CI quality gates), to survival (resilience), to the edge (CDN/caching), and finally to knowing the limit (capacity testing). Together they are the operational backbone under every feature the store ships. Measure, gate, protect, cache, and know your ceiling — in that order.

This was the final post in the Magento 2 Performance/DevOps series.