Azure Redis Cache - Application Performance Improvement

Question

I have a scenario and I would like to know if I am using Azure Redis Cache the proper way because I definitely not see any performance so ever.

The web app allows customer to create, read and update records and assuming those are customer records. There is an SQL db behind in Azure, and has close to 60.000 customer records, and we assume for our example that there is one table, with customer details, name, email, address, and so forth.

How will you guys build this web app in order to improve the performance because it is way faster to query the database directly rather than puting all records to cache. What I currently did using cache:

• For every read including filters (search, sort, etc) I get the data from the Redis Cache, deserialize it as a List<T> and query, fiter, search, etc and return the results.
• For update, I update the record in the sql db, fetch all records from db as a List<T> and store it to cache.
• For creating and deleting same as for update above.

I get zero performance benefits for using the cache. Do I use it wrong?

I think that is a bad idea of serializing lots of data and store it to cache. Any ideas how to make it better?

Answer 1

Although I haven't benchmarked searches across keys in Redis, you can expect O(N) search time because Redis will have to inspect every key to see if it satisfies the query. A database with an index that covers your query will be able to search in much less than O(N) time because it does NOT have to look at every record. I would think that for large data sets, a database could perform better for searches because it doesn't have to look at every record.

Now for the best way to boost performance using Redis.

Redis shines when you have the key for the value you're trying to retrieve. It's crazy-fast in this situation and will crush a SQL DB in performance for a single value lookup. You'll see the most benefit overall if you're working with read-heavy data. For example, if your application had a user preference record per user that had to be examined on each request, this would be a great candidate for caching in Redis. You also get the benefit of offloading traffic from your database and sending it to Redis instead.

Check out the Cache Aside Pattern for a more in-depth explanation.

One other gotcha for working with Redis: make sure you're reusing your ConnectionMultiplexor and not continually trying to reconnect to the Redis cache instance per-request. This is slow, and there's actually a max connection limit per cache.