Net.DistributedFileStoreCache

This repo contains the Net.DistributedFileStoreCache library provides a .NET distributed cache that has two excellent features

• It can get cache values blistering fast – it only takes ~25 ns. to Get one entry in a cache containing 10,000 entries.
  • It can also read ALL 10,000 cache entries in ~85 ns. too.
• It uses a json file as the shared resource which makes it really easy to setup, and you don't need to setup / pay for a database for your cache.

NOTE: The shared resource is a json file and for it to work as a distributed cache all the application's instances must be able to access that file. This would work with Azure's Scale-Out feature with its default setup.

The main downsides is its slower than the database-bases distributed cache libraries when updating the cache values. See Performance figures for more information.

The Net.DistributedFileStoreCache is an open-source library under the MIT license and a NuGet package. The documentation can be found in the GitHub wiki and see the ReleaseNotes.md file for details of changes.

Performance figures

I measure the performance of the FileStore cache String version by the excellent BenchmarkDotNet library. My performance tests cover both reads and writes of the cache on a cache that already has 100, 1,000 and 10,000 cached values in it.

Each key/value takes 37 characters and the size of the cache file are:

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19043.1766 (21H1/May2021Update) Intel Core i9-9940X CPU 3.30GHz, 1 CPU, 28 logical and 14 physical cores .NET SDK=6.0.203 [Host] : .NET 6.0.7 (6.0.722.32202), X64 RyuJIT DefaultJob : .NET 6.0.7 (6.0.722.32202), X64 RyuJIT

Read times

Summary of the read side is:

• Reads a single cache value took ~25 ns at all levels of cache size evaluated at.
• Getting a Dictionary of ALL the cache key/values took ~80 ns at all levels of cache size evaluated at.

NOTE: I tried a read of a SQL Server database containing 200 entries with Dapper and a single took about 300 us.

Write times

Summary of the write side is:

• The time taken to add a cache value to cache goes up as the size of the cache is. This makes sense as unlike a database you are reading and then writing ALL the cache values into a file.
• The async versions are slower than the sync versions, but it does release a thread while reading and writing.
• The SetMany method takes about the same time as a single Set (see AddManyKey100 which adds 100 new entries), so use this if you have many entries to add to the cache at the same time.

NOTE: I tried a write of a SQL Server database containing 200 entries with Dapper and a single INSERT took about 1,000 us. but but the real time would be longer because the SQL needs to see if a entry with the given key already exists, in which case it would need to update the value of the existing entry.