The scale test

A demo shop has forty products and no orders. A real shop has thousands of products and years of orders. Code that is comfortable on the first can fall over on the second, and the difference does not show up until you have customers — which is the worst possible moment to find it.

So we stopped testing on a demo.

What we loaded

A real production shop's data: a 410 MB database dump holding 66,701 orders, alongside its complete uploaded-files tree — around 900 MB and 5,000-odd images, the real product photos, banners and store logos.

That last part matters more than it sounds. Testing with an empty uploads folder means every image request 404s instantly, which is fast and tells you nothing. A shop's real media is part of its load.

The server: 4 GB of RAM, 2 CPU cores. Deliberately modest, because that is the size of box a shop actually starts on, and problems that only appear when resources are tight are exactly the problems worth finding.

What the scale revealed

Several things that were invisible on small data became obvious immediately:

• Pages that ran a database query inside a loop — fine at forty rows, catastrophic at thousands. The 8,614-questions earnings report on the measured results page is the extreme case, but it was not the only one.
• Queries with no index behind them, which a small table hides completely because scanning forty rows costs nothing.
• Listing screens that loaded every matching row into memory in order to show ten of them.
• A cache that kept a copy per unique request, which on a small catalogue is a handful of copies and on a real one is thousands.

None of these are exotic bugs. They are the ordinary consequence of code written and tested against a demo dataset, and they are precisely what a shop owner inherits on day one.

The number that says the most

After the work, the whole working dataset lived in memory: 99.99 % of database reads were answered without touching the disk, on a 515 MB dataset in a 1 GB buffer pool.

That is the real finding, and it is more useful than any single response time. It means the shop is not waiting on storage during normal operation — the pages are fast because the data is where it needs to be, not because one query got tuned.

Throughput, stated carefully

Under 20 concurrent users hitting the search endpoint for 30 seconds, the server sustained roughly 53 requests per second on 2 cores.

Read that as exactly what it says. It describes one endpoint, on this dataset, on two cores. It is not "6amMart does 53 requests per second" — a different screen or a bigger machine gives a different answer, and we did not measure a bigger machine.

Where the boundaries are

Two further honesty notes. Storage-speed figures from these runs are not usable as evidence — they reflect which physical host the virtual machine happened to land on, not the software. And the dataset, real as it is, is one shop: your catalogue's shape will differ, and shape affects which queries matter.

Why we keep the dataset

Every change since is re-measured against the same data. That is the only way a "faster" claim stays true over time rather than describing one afternoon — and it is how the defects were found in the first place, because a defect that only appears at scale needs scale to appear in.