What we learned from load testing Shopware at scale

We ran real-world load tests across seven different infrastructure plans—from Grid to Dedicated Split—using realistic conversion rates, bot traffic blends, and ERP-driven API imports. The findings were clear: performance scales predictably with resources, but only if your code, cache, and configuration keep up. This blog post walks through key results, why API load is disproportionately expensive, and what metrics matter most.

How well does Shopware actually perform under load? This question comes up a lot, especially when teams are evaluating new infrastructure or preparing for traffic surges. So we decided to test it ourselves.

We ran structured, production-style load tests across seven different Shopware PaaS infrastructure plans, from entry-level Grid configurations to high-capacity Dedicated Split clusters. The goal was not to break the system, but to simulate real e-commerce usage under pressure: browsing, buying, and backend automation, all with realistic conversion rates and caching behaviour. Here’s what we found.

Real traffic is more complex than you think

Many performance tests rely on synthetic scenarios, that is, single endpoints hammered at fixed rates. That’s not how real storefronts behave. Our test plan included:

• Anonymous browsing (homepage, categories, search)
• New customer journeys (browse, register, checkout)
• Repeat customer purchases (login and fast-buy)
• API-driven product imports (ERP simulation)

We also introduced realistic conversion rates (~3%), bot-to-user ratios, and caching behaviour. Caches were prewarmed using automated crawlers to mirror real-world deployments.

Key findings from the load tests

1. Shopware scales predictably with resources

As infrastructure plans increased in CPU and memory, Shopware handled more concurrent traffic while keeping response times low. Even modest plans performed well under tuned conditions. For example, a Dedicated Grid Host (DGH32) handled over 7,000 orders per day with sub-second p95 TTFB.

2. The API is a hidden cost driver

API traffic (such as product updates or ERP syncs) generated a disproportionate share of backend load. Even though it represented only 5–10% of total traffic, API requests were responsible for cache invalidations and spikes in CPU usage.

3. Caching strategy makes or breaks performance

Plans with prewarmed Fastly caches maintained consistent response times. Those tested without proper cache priming showed significant latency. Cache fragmentation and poorly structured endpoints led to MISS responses, which immediately degraded throughput.

4. Infrastructure isn’t the bottleneck

In almost every scenario where performance dropped, the issue traced back to code, configuration, or cache invalidation—not the underlying platform. For example, one plugin left in debug mode introduced disk I/O contention that slowed pages to a crawl.

A note on methodology

We used Grafana K6 to simulate traffic and tracked metrics like:

• p95 TTFB (Time to First Byte)
• Peak requests per second (RPS)
• CPU saturation
• Error rate
• Orders/hour and orders/day

Each test ran for 5 minutes with isolated, clean environments. Conversion logic and traffic shaping were applied to mirror real storefront behaviour as closely as possible.

Want to see the full results?

The complete white paper includes:

• Load test results for Grid, DGH, Dedicated, and Dedicated Split plans.
• Detailed performance benchmarks (orders/day, RPS, TTFB, CPU).
• Infrastructure configuration insights.
• Cache invalidation strategies and test design notes.
• Operational best practices for Shopware at scale.

Discover what really impacts Shopware performance at scale 

Get the white paper and explore real-world load test results across seven infrastructure plans. See how caching, APIs, and configuration choices affect response times, error rates, and order volume—so you can scale with confidence.

Download the white paper now to start optimizing your Shopware site