How the 6amMart optimisation was measured

How the 6amMart optimisation was measured

The optimisation results themselves are summarised on measured results. This page is the method behind them: what was held constant, what kind of number each figure is, and the rule every change had to pass before it was accepted.

The short version. Every before-and-after pair was taken on the same machine — 4 GB, 2 cores — against the same shop's data, with the CDN bypassed so the application was being timed and not a cache. Three different kinds of thing were measured — server response times, database query counts, and one build output plus one handset round trip — and they are never combined into a single multiple. And no change was accepted until it returned identical output to the code it replaced.

Three kinds of number, and why they stay apart

A response time, a query count and a byte count are not the same measurement, and quoting one multiple across them would mean nothing. The published rows are grouped accordingly:

• Response times (featured items, search, storefront home, top categories, app configuration on launch) — milliseconds a shopper waits, measured server-side with the CDN bypassed.
• Query counts (store earnings export, product catalogue listing) — how many separate statements the application sends its database to draw one page. "CDN bypassed" is not a meaningful condition for these, because no clock is involved.
• Neither — one row is a byte count read off a build output with no server involved, and one is ten app requests in sequence from a handset over mobile data, which includes a mobile network we did not optimise and cannot.

The query counts matter for a reason a clock hides. A page that sends 8,614 statements holds its database connection open for the whole time it does so, and on a small test dataset each of those statements is fast — so the page looks acceptable in testing and collapses on a real shop.

Where a measurement produced a range, the published multiple is the least flattering the numbers allow: slowest "before" divided by fastest "after", rounded down rather than up. The arithmetic is printed on the results page for each row.

The admin sweep — all 297 pages

The rows above are the shopper's side. The other side was swept separately in August 2026: all 297 admin pages, each requested warm through the real PHP opcache, with the database statements grouped by statement so a repeated one could be seen rather than summed away.

The panel was not broadly slow. 269 of 297 pages already answered in under 200 ms, and the cost was concentrated in a handful of report pages, each slow for a different reason.

Held constant: the same box, the same shop's data, warm requests through the real opcache, before and after.

The worst page is worth its own numbers, because it shows why a total is not a diagnosis. Before the fix it took 20,860 ms, of which 12,430 ms was inside the database driver, and one statement ran 122 times at 87.6 ms each — 10,700 ms of the total on its own. No server setting touched it: a full tuning pass on a rival panel moved it from 20,925 ms to 20,470 ms. It needed the application changed, which is what this work is.

After the round, 256 of 297 pages answer normally and only 22 sit over 200 ms — all but two of those honest one-scan aggregates of the whole order history.

Four admin routes answered a server error to an ordinary GET and were found by the same sweep: two crashed on a stale link or an unknown id, and two pointed at controller methods that do not exist in the codebase at all.

The acceptance rule

Every optimised screen was compared against the stock screen's output before the change was accepted. Faster was never allowed to mean different — the day-wise report's new SQL aggregate had to agree with the old PHP summation to the paisa.

A speed number without that check behind it is not worth publishing, and a page that produces different figures quickly is not an improvement.

What was measured and deliberately not shipped

Two report pages were left alone on purpose. Their cost is one honest scan of the whole order history, which is the job rather than a defect, so they are published as numbers that will not improve.

One candidate index was measured and rejected. A (status, is_approved, order_count) index on the item table was proposed for the popular and rating rails: measured at 15 ms down to 12 ms unforced, 16 ms when forced, with examined rows unchanged, because the database rewrites the query to drive from another table and the plan the index was meant to enable is unreachable. It was not shipped.

The reverse also happened — one measurement corrected a tool rather than the server. A readiness probe reported the item report at 468 ms for a page that runs at about 340 ms, because the probe used tidy INNER JOINs where the application writes LEFT JOINs, and the inner form let the optimiser pick a different plan. Measured on the box: the probe's plan 468 ms, the report indexes ignored 310 ms, the primary key forced 289 ms, join order forced 294 ms, and the application's own join shape 335 ms. The probe now carries the application's exact shape.

The load test, run on both codebases

A separate benchmark drives real HTTP requests through the server's own stack — web server, worker pool, PHP, a fresh database connection per request — stepping concurrency up until throughput stops improving. It runs over loopback, and loopback is exempt from every rate limiter on that server by design, so it measures the stack rather than the throttle.

Held constant: the same 2-core box, both arms, zero failed requests on either.

The second row is higher and does not mean the vendor code is faster. Its database is nearly empty, which is exactly the condition under which the query-count defects above stay invisible.

The same tool times the six heavy report shapes on whatever data it finds: 127–283 ms on the real 66,701-order dataset, sub-millisecond on the small one, and all six present on the untouched vendor schema.

The defects are a separate kind of claim

Most of what was fixed was not speed. 342 defects were closed in the original round and five more in the August 2026 round, and the count is the least interesting part — most of them never showed an error message. They took money, leaked data or lost stock quietly.

Those are reproduction results, not measurements: each one was demonstrated on a running shop with real data before it was fixed, and the published tallies are the conservative ones — 4 of the security holes rated critical and 6 of the defects money-affecting, both lower than the number of items actually listed. Defects fixed has them.

One figure from that work belongs here because it is a measurement of scope rather than of speed: after a live crash was traced to a single unguarded database lookup, 108 call sites reading the same shape, across 24 distinct settings keys, were checked against two separate live databases to establish that the rest were safe. Fixing the one that crashed would not have told us anything about the other 107.

What these numbers do not cover

They do not describe an 8 GB server — none was measured. They do not describe your catalogue, which is a different size and shape. And each row describes one screen on one dataset on 2 cores; change any of the three and the number changes.

Related

Measured results is the summary · How we measure is the method we apply to every round · What we withdrew is the claims that did not survive it.