ASP. NET micro Caching: benefits of a one-second Cache
Abstract
When I start talking about caching, I imagine that contains people immediately stop listening, thinking "my situation requires up-to-the-minute data, so caching isn't an option ". consider the benefits of what I call 'micro caching', in which data is cached for a very small amount of time. in high volume applications, the benefits can be substantial.
| Introduction | |||||||||
I fell in love with caching when I first started playing with it in the early versions of the ASP. net Alphas. I was aware of caching before that, but I 'd never really gone to the effort to seriously implement a cache engine in an ASP app, and with ASP. net, I didn't have. the thing that attracts me to caching is its impact on performance without requirements (usually) for major re-architecture of the system. In this article, I'm going to discuss what I callMicro caching, Because it involves caching things for very brief periods. one of the major downsides of caching in general is that by definition the data is not fresh. how big a problem this is depends on the application and the user's requirements, which is why it is important to determine the user's tolerance for stale data when gathering requirements. the knee-jerk answer is going to be 'I need live data all the time', but hopefully with the data in this article, you will be able to convince the user/client that perhaps it wocould be OK if the data were, say, a second or two old, if it meant they cocould host the application on half as much hardware.
|
| Results without caching | |
Running the test without any caching on the Web server resulted in 16,961 requests and an average requests per second of 56.54. the time to first byte (ttfb) and time to last byte (TTLB), which are useful measures of the site's performance from an individual user's perspective, were both 52 Ms -- instant as far as a user is concerned. for most web applications, anything under one second is an acceptable TTLB. Below is a graph of requests per second over time for the page without caching. Figure 1 |
| Test page with caching | |
For the second part of the test, I modified the test page by adding one line of code to default. aspx: <% @ Outputcache duration = "1" varybyparam = "NONE" %> The new default. aspx then looked like this: <% @ Page Language = "C #" codebehind = "default. aspx. CS "autoeventwireup =" false "inherits =" microcache. _ default "enablesessionstate =" false "enableviewstate =" false "%> The same test was run against this page. |
| Results With caching | |
Running the test a second time against a page with one second of output caching enabled resulted in a total of 74,157 requests and an average requests per second of 247.19. the ttfb and TTLB were both 11 ms. so, compared to the non-cached page, the throughput increased by over 400% and each page took 80% less time to load, five times the performance. Figure 2 below shows a graph of requests per second over time. Figure 2 |
The next figure shows both tests, side-by-side.
Figure 3
| Analysis and Summary | |
Clearly, even just a second's worth of caching can have a big impact on performance for a high-volume application. it's easy to see why this is the case if we look at the database's performance during this test. I ran the test with two performance counters: Sqlserver: SQL statistics/batch requests/sec In the non-caching test, the SQL Server requests/sec counter averaged 56.2 requests per second. in the micro-caching test, it averaged 1.0 request per second. obviusly, the database was not having to do nearly as much work. however, not all of the savings were on the database side. loading data into a dataset is relatively expensive as well, as is data binding. although there aren't any performance counters for these activities specifically, we know they were occurring once per request in the first case, and once per second in the latter case, so we dropped a lot of work from the ASP. net engine's plate as well. Typically, the database and the web server will reside on separate boxes. the operation in database load wowould clearly benefit the database server, which is a very good thing since, historically, database servers are much more difficult to scale out than Web servers. in addition, it will reduce network traffic between the web and database servers, which will further enhance performance, and the operation ction in Web server load is also helpful, of course, since it reduces how many web servers wocould be needed (or how powerful each one wowould need to be ). Summary Caching is a very useful tool to take advantage of when designing applications. it is not a panacea, and like any tool, it can be used improperly. but even in situations where data needs to be up to the second, adding one second's worth of caching can make a big impact on application performance. remember to ask your users how much they can tolerate out-of-date data and try to get them to at least sign off on one-second-old data if you can, since that will allow you to take advantage of techniques like the one described here. |
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
