Skip to main content
Metrics type: Key Metrics • Category: Cross-Platform: Revenue at Risk

​
At a glance

A dual-axis view that plots MariaDB queries-per-second against the storefront’s order rate on the same timeline. When the two lines move together, your database load is paying for itself: more queries, more orders. When QPS spikes but orders stay flat, the database is working hard for nothing, and the usual culprit is a bot, a scraper, or a runaway integration hammering the catalogue. This card turns a raw database-load signal into a revenue-relevance question: is this traffic worth serving?

​
Calculation

QPS is derived from the Questions status counter (or Queries, depending on whether you want to include stored-procedure internals): Vortex IQ samples the counter, takes the delta between samples, and divides by the elapsed seconds to produce queries per second. The order rate is the count of order events from the linked storefront over the same window, expressed per minute or per second to share the axis. The card plots both on a dual axis so the correlation between them is the readable signal, not either line alone. Per the card’s alert rule, the trigger condition is a qps spike with no order spike: the engine looks for a window where QPS rises sharply above its recent baseline while the order rate stays flat. That divergence is the bot/scraper fingerprint, traffic that costs you database load and infrastructure spend while generating zero revenue. A spike in both lines together is healthy demand and does not alert.

​
Worked example

A Shopify store on a self-managed MariaDB backend (custom catalogue service) normally runs ~1,200 QPS at ~3 orders/min during the day. Snapshot taken 14 Apr 26, 13:20 to 13:35 BST, 15-minute window. QPS has jumped 5.8x while orders are flat (and dipping). The headline shows the alert fired: QPS spike with no order spike. This is not a flash sale; a sale would lift both lines. It is the signature of a catalogue scraper crawling every product and variant page as fast as it can, each page firing a burst of database reads. The on-call response runs in two tracks:
  1. Protect the database now. A 6x query load can saturate the connection pool and slow legitimate shoppers. Check Connection Pool Saturation % and Query Latency p95 (ms); if real customers are now seeing slow pages, the scraper is causing collateral damage and needs blocking at the WAF or CDN immediately.
  2. Confirm it is a scraper, not a bug. Pull Top 10 Slowest Queries (digest) and SHOW PROCESSLIST. A scraper shows as a flood of identical catalogue-read digests from a narrow set of source IPs. A runaway integration or an N+1 regression after a deploy shows a different fingerprint (often a single digest exploding in call count). The fix differs: block the IPs for a scraper, roll back or patch for a code regression.
If the scraper tips the pool over, the genuine 3 orders/min (at, say, £64 AOV that is ~£192/min, ~£11,500/hour of real revenue) is what is actually at stake, not the worthless scraper traffic. Three takeaways:
  1. QPS alone is not a health metric. High QPS is good if it tracks orders and bad if it does not. This card exists precisely because a raw QPS number cannot tell you which it is; the order-rate overlay can.
  2. The dangerous case is divergence, not magnitude. A genuine 5x QPS spike during a flash sale is fine because orders rise with it. The alert fires only when the lines decouple, because that is the only pattern that means “load without value”.
  3. A scraper is also a database-stability risk, not just a cost. The collateral is the threat: a scraper that saturates the connection pool degrades the experience for paying shoppers. Treat a no-order QPS spike as a potential availability event, not merely a billing annoyance.

​
Sibling cards

​
Reconciling against the source

Where to look in MariaDB’s own tooling:
Compute QPS yourself from the counter: sample SHOW GLOBAL STATUS LIKE 'Questions'; (or 'Queries') twice a few seconds apart and divide the delta by elapsed seconds. SHOW GLOBAL STATUS LIKE 'Uptime'; gives the lifetime average (Questions / Uptime). SHOW PROCESSLIST; or SELECT * FROM information_schema.PROCESSLIST reveals who is running the flood and from which host. performance_schema.events_statements_summary_by_digest shows which query shapes are exploding in COUNT_STAR. On managed platforms: AWS RDS / Aurora “Queries” CloudWatch metric or Performance Insights, SkySQL monitoring QPS panel.
The order-rate axis is verified against the storefront’s own analytics: Shopify Analytics orders-over-time, BigCommerce Analytics, or Adobe Commerce Reports → Orders. Why our number may legitimately differ from a manual reading: Cross-connector reconciliation:

​
Known limitations / FAQs

QPS spiked but it was a real flash sale. Why did the card not alert? Because orders rose with it, that is the design. The alert fires only on divergence: QPS up, orders flat. A flash sale lifts both lines, so the ratio stays healthy and no alert fires. If a genuine sale ever triggers the alert, it usually means orders are not landing despite the traffic (a checkout failure), which is itself worth investigating. The card alerted but it was a legitimate batch job, not a scraper. How do I stop the noise? Known internal jobs (nightly reindex, analytics export, ETL) produce exactly the no-order spike fingerprint. Exclude them by source IP or user in the Alert Rules tab, or schedule them in a window the card knows to discount. Do not widen the threshold globally, as that would also hide real scrapers. Is high QPS bad? Not by itself. High QPS that tracks orders means the store is busy and the database is earning its keep. The card is agnostic about magnitude; it cares only whether the load corresponds to revenue. Use Queries per Second (live) for the raw number and this card for the “is it worth it?” judgement. Should I sample Questions or Queries for QPS? Questions counts statements sent by clients and excludes statements executed inside stored procedures and triggers; Queries includes them. For a storefront-facing read of shopper-driven load, Questions is usually the more meaningful counter. The connector documents which it uses; match it when reconciling manually. A no-order QPS spike is hitting only one Galera node. Why? A scraper coming through a sticky-session proxy or hitting one hard-coded node concentrates its flood there. That node can saturate while siblings stay idle. Cross-reference Pool Saturation Across Galera Nodes vs Traffic to see the per-node picture and rebalance or block at the proxy. Does this card work without a storefront connector? No. The order-rate axis comes from the linked Shopify, BigCommerce or Adobe Commerce connector. Without it the card cannot answer the core question (is this load generating orders?) and stays empty. Link the storefront connector to activate the dual-axis view. Could a no-order spike be a code regression rather than a scraper? Yes, and the distinction matters. A scraper shows as many catalogue-read queries from a few external IPs; a regression (for example a new N+1 query after a deploy) shows as one digest exploding in call count from your own application servers. Use Top 10 Slowest Queries (digest) and SHOW PROCESSLIST to tell them apart: block IPs for a scraper, roll back or patch for a regression.

​
Tracked live in Vortex IQ Nerve Centre

MariaDB QPS Spike vs Ecom Order Rate is one of hundreds of KPI pulses Vortex IQ tracks across MariaDB and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.