Performance Monitoring

Dino is built for speed. The Performance Monitoring tools let you verify this on your own store.

How the engine stays fast

Fingerprint-based memoization

The engine creates a “fingerprint” of the current cart state (items, quantities, customer, currency). If the cart hasn’t changed since the last evaluation, the cached result is reused immediately — no recalculation needed.

Transient caching

Discount definitions, zones, and per-currency price lists are cached in WordPress transients. This avoids database queries on every page load.

Lazy evaluation

Discounts are only evaluated when a cart exists. Product pages, category pages, and the homepage don’t trigger the discount engine unless product-specific pricing is being displayed.

Enabling Performance Tracking

Open the Dev Tools admin tab — the Performance Log panel is the entire page. Flip on Enable Performance Tracking at the top. The toggle writes the performance_tracking flag to dino_discounts_global_settings; the engine reads it once per request on the front-end.

When tracking is enabled, every front-end request that evaluates discounts adds a structured entry to a JSON-lines log file in wp-content/uploads/dino-discounts/. Each entry records:

• Timestamp (ISO 8601, store timezone)
• URL and HTTP method of the request
• Evaluation count — how many cart evaluations ran in the request
• Total engine time in milliseconds
• Page time in milliseconds (the engine’s share of total render)
• Percent of page — engine time as a share of total page time
• Memoization hits / misses — fingerprint cache stats
• Internal cache stats — rules, settings, product-tag, zone, currency caches
• Per-evaluation breakdown — duration and cache origin per call
• Markers — any explicit telemetry markers added via the API

Viewing the log

Refresh the Dev Tools page to see the most recent entries — the Performance Log panel reads the log file via the REST API (GET /dino-discounts/v1/performance/log) and groups entries by URL so you can spot outliers. The grouped summary shows mean / P95 duration per URL, evaluation count, and cache hit rate.

The log file is capped at a fixed number of entries; old entries are trimmed periodically. Clear the log from the admin tab when you want a clean baseline before a benchmarking run.

For debugging only

Tracking adds a small overhead to capture per-request data. Leave it on while you’re evaluating the plugin or chasing a perf regression, but disable it on a production store under heavy traffic — the log file grows on every request.

What to expect

On a typical WooCommerce store:

• Discount evaluation: about 2ms on a typical store (~25 active discount rules on a 10-item cart), staying in the low double-digit milliseconds (around 12ms) even on a large 50-item cart. Engine cost scales with cart size × active-rule count, so it grows as you add rules and items — it is not flat. (Benchmarked June 2026 on PHP 8.3+ with the container-free engine benchmark, make engine-bench, which isolates the engine’s own CPU cost.)
• Memoization hit rate: > 90% on repeat cart-fragment refreshes within a request — repeat evaluations of an identical cart are served from cache, so production is usually faster than the uncached numbers above
• Memory overhead: < 1MB additional per request

If you see evaluation times significantly higher than this, the usual cause is a large number of active rules (cost is roughly proportional to rule count × cart size) or complex targeting conditions across them. Consider simplifying targeting or paring back the number of always-on rules.

Independent of the analytics path

Performance Monitoring captures hot-path timing data — the cart-eval inner loop. The Discount Analytics tab queries order-level discount usage from the orders database; the two surfaces don’t share a code path, so opening Analytics never adds load to the cart engine.

What’s next

• Discount Analytics — the order-level dashboard (independent of the hot path)
• Caching — the transient layer behind the hot-path numbers above