DragonflyDB Power — Cache Deep Dive

Replaces ~95% of MySQL calls with in-memory responses. Slow queries return in microseconds, not seconds.

Caching is the highest-leverage performance improvement available to any web application. For Magento specifically, where a single uncached page request can trigger 40–200 MySQL queries and dozens of PHP function calls, a well-tuned cache layer is the difference between a 4-second load time and a 40-millisecond one.

This page explains every layer of Accelerate Guru's caching architecture: how page caching works, how the cache key is constructed, how MySQL query caching works, and how everything is invalidated in real time without manual purges.

#Architecture overview

                     ┌──────────────────────────────────────┐
Request arrives ────▶│         Accelerate Guru Edge          │
                     │                                       │
                     │  1. Build cache key (URL + variations)│
                     │  2. Lookup in DragonflyDB             │
                     │                                       │
                     │  ┌────────────────────────────────┐  │
        HIT (90–95%) │  │  DragonflyDB                   │──┼──▶ Response (< 2 ms)
                     │  │  In-memory, Redis-compatible   │  │
                     │  └─────────────┬──────────────────┘  │
                     │                │ MISS (5–10%)         │
                     └────────────────┼─────────────────────┘
                                      │
                                      ▼
                     ┌──────────────────────────────────────┐
                     │         Magento (PHP + MySQL)         │
                     │                                       │
                     │  ┌────────────────────────────────┐  │
                     │  │  MySQL Proxy (optional)        │  │
                     │  │  Caches SELECT results         │  │
                     │  │  Invalidates on writes         │  │
                     │  └────────────────────────────────┘  │
                     └──────────────────────────────────────┘

#Page cache

#What is cached

Accelerate Guru caches full HTML pages — the complete HTTP response body, including headers. Every request for a cacheable URL checks DragonflyDB first. If a valid entry exists, the response is returned immediately without contacting Magento at all.

A page is cacheable when all of the following are true:

1. The HTTP method is GET or HEAD.
2. The URL is not in cache_exclude_paths (checkout, account, etc. are always excluded).
3. The request does not carry an admin session cookie (adminhtml=). Logged-in customer requests are cached per-customer when enable_per_customer_cache = true (the default), using a shorter TTL configured by customer_cache_ttl_secs.
4. The response from Magento has a cacheable status code (200, 301, 404) and does not set a Cache-Control: no-store or Set-Cookie with a session-identifying value.

#Cache key anatomy

The cache key is a SHA-256 hash incorporating:

scheme (http|https)
+ host (including port)
+ path
+ filtered query string (marketing params removed)
+ customer group ID (from session lookup)
+ vary cookies (esw-currency, store, etc.)
+ X-Magento-Vary value (customer segment)

Each dimension is separated by an explicit delimiter to prevent collisions. This means:

• https://shop.com/ and http://shop.com/ get different cache entries (prevents mixed-content attacks on masked domains).
• A visitor with esw-currency=USD and a visitor with esw-currency=EUR get different cache entries.
• A wholesale customer (group 2) and a retail customer (group 0) get different cache entries.
• A URL with ?utm_source=google and the same URL without it get the same cache entry.

#X-Magento-Vary and customer segments

Magento sets the X-Magento-Vary cookie for every visitor on multi-store or customer-group-priced catalogues. The value is a hash of the visitor's segment (customer group, store view, currency, locale).

Before Accelerate Guru (or with naive caches): any request carrying X-Magento-Vary is treated as "personalised" and bypasses the cache entirely. This means most visitors on a multi-store Magento — the majority of real-world deployments — never hit the cache.

Accelerate Guru's approach: the X-Magento-Vary value is extracted and mixed into the cache key as a segmentation dimension. All visitors with the same segment value share a single cache entry. Visitors with different segment values get separate entries. Nobody bypasses the cache.

Result: on a typical 3-store, 2-currency Magento, this turns a ~5% cache hit rate into an ~85% hit rate overnight.

#Cache TTL and invalidation

The default TTL is controlled by cache.cache_ttl_fallback (default: 86400 seconds / 24 hours). This is the fallback TTL used when the MySQL proxy is not enabled.

When the MySQL proxy is enabled, pages are cached indefinitely (TTL = 0) and invalidated automatically when the underlying data changes. This is the recommended configuration for production.

#MySQL query cache

The MySQL proxy is Accelerate Guru's most powerful (and most optional) feature. When enabled, it intercepts all MySQL traffic between Magento's PHP processes and the database:

Magento PHP ──▶ localhost:3307 (Accelerate Guru proxy) ──▶ localhost:3306 (MySQL)
                        │
                        ▼
                  DragonflyDB (query results)

#How to enable it

1. In magento_ultra.ini:

[mysql_proxy]
enabled        = true
listen_port    = 3307
mysql_host     = 127.0.0.1
mysql_port     = 3306
mysql_user     = magento_user
mysql_password = secret

2. In Magento's app/etc/env.php, change the db.connection.default.port from 3306 to 3307.

3. Restart Accelerate Guru.

#What is cached

All SELECT queries are candidates for caching. The cache key is the normalised, whitespace-collapsed SQL text. The result is stored in DragonflyDB.

Invalidation is automatic and write-aware: when Accelerate Guru sees a INSERT, UPDATE, DELETE, REPLACE, or TRUNCATE on a table, it immediately evicts all cached queries that referenced that table. Magento's cache invalidation signals (product saves, price rules, CMS changes) also trigger eviction.

#Performance impact

#Cache warming

You can pre-populate the cache at startup by providing a sitemap:

[mysql_proxy]
warmup_sitemap      = https://yourstore.com/sitemap.xml
warmup_concurrency  = 4

At startup, Accelerate Guru fetches every URL in the sitemap with warmup_concurrency parallel connections. By the time the first real visitor arrives, the cache is already warm.

For very large catalogues (100K+ products), set warmup_concurrency to 8–16 and be aware that this will generate significant load on the origin server at startup.

#Real-time cache invalidation via SSE

When Magento processes a product save, price update, or stock change, it updates the database. The MySQL proxy intercepts these writes and:

1. Evicts the affected SQL query results from DragonflyDB.
2. Evicts the affected page cache entries (product pages, category pages that list the product).
3. Sends an SSE (Server-Sent Events) message to all connected browser service workers.
4. Each browser's service worker receives the event and marks the affected pages as stale — the next visit fetches fresh content automatically.

The result: a price change in Magento admin is reflected in every open browser tab within seconds, with zero manual purge, zero deploy, and zero page reload.

#Static asset cache

CSS and JavaScript assets, once minified and compressed by the edge, are stored in DragonflyDB with a default TTL of 7 days (static_asset_cache_ttl = 604800). This means the CPU cost of minification happens once per asset version, not on every request.

Asset cache keys are content-addressed — if the asset URL changes (Magento's _version/1234567890/ prefix changes on deploy), the new asset is fetched and cached fresh.

#Monitoring cache performance

The /stats-ag dashboard shows:

• Overall hit rate (last 5 min / last hour / all time)
• Pages cached (count of unique cache entries)
• Cache size (bytes stored in DragonflyDB)
• Invalidation events (count of MySQL-triggered evictions)
• Time saved (estimated seconds not spent in Magento)

For a healthy production store, you should expect:

#Tuning the cache

#Exclude paths that cannot be cached

Add any path that returns user-specific content to cache_exclude_paths:

[cache]
cache_exclude_paths = /customer/,/checkout/,/wishlist/,/sales/,/newsletter/,/paypal/,/multishipping/,/my-custom-account/

#Segment by additional cookies

If your store uses custom cookies to differentiate users (A/B testing cookies, custom store switchers), add them to vary_cookies:

[cache]
vary_cookies = esw-currency,esw-location,store,my_ab_test_cookie

#Handle aggressive marketing parameters

Add any new tracking parameters used by your campaigns:

[cache]
cache_exclude_params = gclid,utm_source,utm_medium,utm_campaign,utm_content,utm_term,fbclid,msclkid,ttclid