(Added LazyCache in to the Testing)
One of the essential factors in building high-performance, scalable Web applications is the ability to store items, whether data objects, pages, or even parts of a page in memory the initial time they are requested. You can save these items on the Web server or other software in the request stream, such as a proxy server or at the browser. This allows you to avoid recreating information that satisfied a previous request. Known as caching, it will enable you to use many techniques to store page output or application data across HTTP requests and reuse it. When the server does not have to recreate information you save time and resources, and throughput and scalability increase.
It is possible to obtain significant performance improvements in ASP.NET applications by caching frequently requested objects and data in either the Application or Cache classes. While the Cache class indeed offers far more flexibility and control, it only appears to provide a marginal advantage regarding increased throughput over the Application class for caching. It would be challenging to develop a testing scheme that could accurately measure the potential benefits of the Cache class’s built-in management of lesser-used objects through the scavenging process as opposed to the fact that Application does not offer this feature. The developer needs to decide this case and should be based on the needs and convenience of the project and its usage patterns.
In the article, I’ll be looking at the application caching and what is the most effective and scalable options. If you would like to know more about the web caching then take a look at the Microsoft Caching Architecture Guide for .NET Framework Applications
So we all know that caching increases performance, what I am not getting into here is when it should be used or when it shouldn’t be used. I’m more interested in the performance and scalability of the caching used.
The performance testing I am going to use the following different caching methods:
- No Caching
- Memory Cache
- Memory Cache using Statics
- Memory Cache using Singleton
- HttpRuntime Cache
- Redis Cache (You’ll need to setup a local Redis server in order to see the results, here is the Windows Redis Service installer)
- LazyCache
I’ve tried to provide some different options that are available for Caching, if you know of any others, please let me know and I’ll add them to this post.
There are two types of tests I am using a small test which waits for 30 milliseconds and then returns back the current date and time:
Thread.Sleep(30); return System.DateTime.UtcNow.ToString(CultureInfo.InvariantCulture);
then a test to generate a much large object of 267 Mb
public IEnumerable<Block> GetData()
{
// should eat around 267 Mb of RAM.
var blocks = new Block[512 * 512 * 1];
for (var i = 0; i < (512 * 512) * 1; i++)
{
blocks[i] = new Block();
}
return blocks;
}
Both are straightforward tests, by no means are they an accurate representation of real-world methods, but they do show you how it affects the performance when using different Caching.
The idea is to iterate around these test 1,000 times and record how long it takes for each test, what I don’t do here is work out the amount of memory is being used (if you know of an easy way to include this, please let me know).
I won’t go into great details here on the results of the tests as I think you’ll find them self-explanatory in the test application, attached at the bottom of this post.
Few things to note about the testing and results is that you should use a Paralling process for the examination, as this will be much closer to the real world multi-threading environment.
Also, careful consideration should be given to using locking in the Cache module, as you don’t want the same cache key function running while another one is trying to process the same function, it should wait until the process has finished and stored it into the cache to increase performance.
Here is the sample code with different sample tests showing how useful each option is