Magento 2 Redis and OpenSearch Optimization

Redis and OpenSearch are where a lot of Magento stores quietly lose their performance headroom. Both work fine in a demo and both fall over at scale when they're left on defaults — and because they sit in the infrastructure layer, the symptoms (slow TTFB, spiky checkout, dropped carts) rarely point straight back at the cause. This is the configuration that actually matters.

A version note first: Magento 2.4.8 supports Redis 7.2 and, newer, Valkey 8 — the open-source Redis fork Magento now recommends for new installations. Valkey is a drop-in replacement, so everything below applies to both; where we say "Redis," read "Redis or Valkey." Search runs on OpenSearch 2.19 on 2.4.8 (OpenSearch 3 lands in the 2.4.8-p4 patch line). Verify against your exact version before you change anything.

Redis: cache and sessions are not the same job

The most common mistake is running Magento's default cache, page cache, and sessions through one Redis instance on defaults. They have opposite requirements, and sharing punishes all of them.

Split them into separate databases — and, as you'll see, separate instances for the part that matters. A single-node env.php cache config:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
                'compression_lib' => 'zstd',
            ],
        ],
        'page_cache' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '0',
            ],
        ],
    ],
],

Two things worth knowing here:

• If you run Varnish as your full-page cache — and on a production store you should — Varnish is your page cache. The Redis page_cache above is the fallback for stores not on Varnish. Don't expect Redis page cache to do Varnish's job.
• On multiple web nodes, don't use the plain Redis backend for the default cache. Use Magento\Framework\Cache\Backend\RemoteSynchronizedCache — an L1 in-memory cache on each node backed by an L2 Redis — so nodes don't serve stale cache to each other. On a single node the plain Redis backend is fine.

Sessions: separate instance, different eviction policy

Sessions go in their own place, with their own rules:

'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6380',
        'database' => '0',
        'disable_locking' => '0',
        'max_concurrency' => '6',
        'compression_threshold' => '2048',
        'compression_library' => 'gzip',
    ],
],

Note the port: 6380, a different instance. Here's why that matters, and it's the detail most stores get wrong.

Memory limits and eviction — the part that bites

A Redis instance has one maxmemory-policy for every database inside it. That single fact drives the whole architecture:

• Cache instances want allkeys-lru. When they fill, Redis should drop the least-recently-used entries gracefully. The alternative, the default noeviction, throws hard errors when Redis fills — which surfaces as random Magento failures under load.
• The session instance must not use allkeys-lru. Evicting a session key logs a customer out or empties their cart mid-purchase. Sessions want noeviction (with enough memory provisioned) or volatile-lru.

Because one instance can't hold two policies, cache and sessions belong on separate Redis instances — not just separate databases. Per instance:

# cache instance (6379)
maxmemory 2gb
maxmemory-policy allkeys-lru

# session instance (6380)
maxmemory 1gb
maxmemory-policy noeviction

Then actually watch for eviction, because silent eviction is silent cache cold-start:

redis-cli -p 6379 info stats | grep evicted_keys
redis-cli -p 6379 info memory | grep used_memory_human

If evicted_keys climbs steadily on the cache instance, either the working set outgrew maxmemory or something is caching far too much — investigate before you just raise the limit.

OpenSearch: sizing and the settings that move the needle

OpenSearch is where category, search, and layered-navigation performance is won or lost on a large catalog. Point Magento at it explicitly:

bin/magento config:set catalog/search/engine opensearch
bin/magento config:set catalog/search/opensearch_server_hostname 127.0.0.1
bin/magento config:set catalog/search/opensearch_server_port 9200

Then the cluster-level settings that matter most:

• Heap sizing. Set the JVM heap to roughly 50% of the machine's RAM, and never above ~31 GB (past that you lose compressed object pointers and effectively waste memory). Leave the other half for the OS file cache OpenSearch relies on. A box with OpenSearch heap set to 90% of RAM is slower, not faster.
• Shards and replicas. A single-node setup wants 1 shard, 0 replicas — replicas on one node do nothing but cost memory. Add replicas only when you have a real multi-node cluster for high availability.
• refresh_interval during bulk reindex. Temporarily raising it (or setting -1) during a full reindex cuts indexing time significantly, since OpenSearch isn't making every change searchable in near-real-time while it works.

Indexing strategy

Fast search infrastructure doesn't help if Magento is fighting its own indexers:

• All indexers on Update by Schedule, not "Update on Save." On-save reindexing locks tables and stalls both storefront and admin on a large catalog. Check with bin/magento indexer:show-mode.
• Cron must be healthy — MView batches catalog changes to the indexers through cron, so broken cron means stale search results and a growing backlog. bin/magento cron:status.
• Turn Flat Catalog off. It's deprecated, and now that search runs through OpenSearch it adds indexing overhead with no query benefit. It lingers in stores only because old guides still recommend it.
• Disable search features you don't use — suggestions and recommendations add query load. If your storefront doesn't surface them, turning them off is free headroom.

Verifying under load

Every setting here holds on an idle box. The question is whether it holds at peak:

• Load-test category and search pages, not just the homepage — they're the ones that lean on OpenSearch.
• Watch Redis eviction and memory during the test, not after. Eviction under load is exactly the failure mode that never shows up in a quiet check.
• Confirm Varnish is still doing the page-cache work and Redis is only handling the default cache and sessions it should be.

What we'd check first

On a slow store, in order: is the default cache on Redis and healthy; are cache and sessions on separate instances with the right eviction policies; is Varnish (not Redis) serving the full-page cache; is OpenSearch heap sized sanely with the right shard count; and are indexers on schedule with cron alive. That short list catches the large majority of Redis and OpenSearch problems we find — and it's the foundation the rest of a Magento performance project builds on.

Emyrix does Magento and Adobe Commerce infrastructure and performance work — caching architecture, search tuning, and the load testing to prove it holds. If your store is slow and you'd rather know why than guess, get in touch.