nopCommerce Caching and Redis: When You Need It and How to Set It Up

Redis is often suggested as the fix for a slow nopCommerce store. Sometimes it is; often it makes no difference, or makes things slower. This guide explains how nopCommerce’s cache works, the four distributed cache options, when each one fits, and how to set up Redis, based on the 4.90 and 5.00 source code.

How nopCommerce caching works

nopCommerce caches the data it reads on almost every page: settings, categories, the menu, URL slugs, prices and permissions. Each entry is kept for 60 minutes by default, and is removed as soon as the data behind it changes in the admin area. That’s why changes appear straight away without clearing anything.

By default the cache lives in the application’s memory. That’s as fast as caching gets, but each server has its own copy. On two servers, a price changed through server A is still cached on server B, so customers see different prices depending on which server answers. The distributed cache fixes that.

The cache options

Scroll the table sideways to see every column.

Redis synchronised memory keeps the cache in each server’s memory, as the default does. When a server changes or removes an entry, it tells the others through Redis, in batches every half second, and they drop their copy. Reads never leave the server; only changes cross the network.

Which one to use

• One server: leave the distributed cache off. Adding Redis only adds network calls.
• Several servers behind a load balancer: redissynchronizedmemory. It’s the default type once you turn the cache on, and the fastest option for a web farm.
• Several servers, memory is tight: plain redis. Entries live once, in Redis, instead of on every server, at the cost of a network call for each read.
• Several servers, no Redis available: sqlserver. It works, but puts more load on the database the cache is meant to protect.

Setting up Redis

1. 1Use a Redis server close to the web servers, in the same network or region. A managed service (Azure Cache for Redis, Amazon ElastiCache) saves running it yourself.
2. 2Require a password and TLS, and don’t expose Redis to the internet.
3. 3Edit DistributedCacheConfig in App_Data/appsettings.json on every server, or in Configuration → App settings in the admin area.
4. 4Restart the application on every server. The cache type is read only at startup.
5. 5Change a product price in the admin area and check it on each server.

"DistributedCacheConfig": {
  "DistributedCacheType": "redissynchronizedmemory",
  "Enabled": true,
  "ConnectionString": "redis.internal:6379,password=YOUR_PASSWORD,ssl=True,abortConnect=False",
  "SchemaName": "dbo",
  "TableName": "DistributedCache",
  "InstanceName": "mystore",
  "PublishIntervalMs": 500
}

Keep the password out of the file in source control: every setting can also be set as an environment variable, such as DistributedCacheConfig__ConnectionString. The separate CacheConfig section sets DefaultCacheTime, the cache lifetime in minutes.

Using SQL Server as the cache

nopCommerce doesn’t create the cache table itself. Create it once with Microsoft’s tool, using the schema and table name from your settings, then set the type to sqlserver and the connection string to the database that holds the table:

dotnet tool install --global dotnet-sql-cache
dotnet sql-cache create "Server=...;Database=nopcommerce;..." dbo DistributedCache

A separate database for the cache keeps its writes away from the store’s own database.

A web farm needs more than a shared cache

• Data protection keys: stored as files in App_Data/DataProtectionKeys. Every server needs the same keys, or customers are signed out when a request moves between servers.
• Pictures and uploads: must be on shared storage, such as the bundled Azure Blob storage plugin.
• Scheduled tasks: run on every server. Check that tasks which should run once, like sending queued emails, behave correctly, and see scheduled tasks on web farms if they stop running behind a load balancer.

Our hosting guide covers running nopCommerce on several servers in more detail.

When the cache isn’t the problem

nopCommerce already caches in memory, so a slow store on one server rarely gets faster with Redis. The usual causes are elsewhere:

• Slow database queries, often from large catalogues, missing indexes or an undersized database server.
• Plugins or theme code that query the database on every page, outside the cache.
• Code that clears the whole cache too often, for example an import or integration that saves settings in a loop.
• Large, uncompressed images and too many scripts in the theme.

Rule out the basics before profiling: our free plugin lets you check task and store health with StorePulse, including overdue scheduled tasks, error spikes and database growth.

Measure first: find the slow pages and what they spend their time on, then fix that. That’s where our performance optimisation service starts.

Frequently asked questions

Next steps

On one server, leave caching as it is and look at what’s slow. Moving to several servers, use Redis with synchronised memory and share the keys and files too. If you’d like a second opinion on either, send us your setup.