Query benchmark: methodology & results
Every Wishmio storefront operation runs in under 100 database queries, and that cost is flat in list size — item #50 costs the same as item #1. This is a published spec enforced in CI, not a marketing average.
The curve
Queries per add as a wishlist grows from 0 to 50 items.
Method
Docker: WordPress (PHP 8.3, MariaDB 11), WooCommerce current, 60 seeded products, guest session, no object cache (worst case). A 19-line mu-plugin logs get_num_queries() per request on shutdown — measurement without instrumentation bias.
The harness adds 51 products via REST, then reads, counts, and removes; it asserts the budget and flatness (add #50 ≤ add #1 + 5 queries).
Results — 2026-07-10, v0.1.0, WP + Woo current
| Operation | Queries |
|---|---|
| Add item #1 | 66 |
| Add item #50 | 60 (flat — O(1)) |
| Read full list @ 51 items | 56 (ETag'd; repeat visits 304) |
| Count @ 51 items | 47 |
| Remove 1 item @ 51 | 55 |
REST-baseline overhead (an empty WooCommerce REST request) accounts for most of this, so Wishmio's marginal cost is a small, flat handful of queries per operation regardless of list size. Caps, rate limiting, and share checks are all inside these numbers.
Reproduce it yourself
The budget is enforced in CI on every push — this isn't a one-time measurement. Run the same script locally:
scripts/dev-setup.sh python3 scripts/bench.py
The script seeds 60 products, drives 51 real REST requests against a guest session, and exits non-zero if any operation exceeds budget or if adds aren't flat in list size.
House rules
- Only our own measurements — no third-party numbers, ever.
- Growth curves, not single points — a flat line across list sizes is the claim, not a best case.
- Fully reproducible — the exact script that produced this page's numbers is the one that gates our own releases.