ASP. NET: what is the role of cache in one second?

Source: Internet
Author: User
At least beyond my imagination.
Details: http://aspalliance.com/251
To facilitate reading, I copied the full text:

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.

Server and Test Setup

The test server had following specifications:

  • 1 GHz P3 Processor
  • 512 MB RAM
  • Windows Server 2003
  • SQL Server 2000

To test the page, I used Application Center Test (ACT), running locally. everything in this test is running on one box, which I realize has some implications as far as where the bottlenecks in performance will occur. during all tests the CPU was maxed out, indicating that increased performance cocould have been achieved with a more powerful box and/or by splitting the work between several servers. however, the point of this test was not to achieve the maximum performance possible for this trivial example -- it was to measure the effects of a small amount of caching on a simple but high-volume application.

The test script consisted of a single request to my default. ASPX page. the script was constructed to use three simultaneous users for five minutes with thirty seconds of "ramp-up" time (to ensure the app had compiled and the SQL server was awake and running full speed). act, unlike other tools such as LoadRunner, does not let you add "think time" between users 'requests without editing the VBScript by hand, so although there are only three users, they are hammering the server because there is no delay between the completion of one of their requests and the initiation of their next request.

Test page without caching

I created a simple ASP. NET page that CILS "select * from products" against a local instance of the northwind database, fills a dataset with the result, and binds it to a DataGrid. to limit the Web server overhead, I disabled viewstate and sessionstate on the page. the page's code without caching was as follows:

Default. aspx

<% @ Page Language = "C #" codebehind = "default. aspx. CS "autoeventwireup =" false "inherits =" microcache. _ default "enablesessionstate =" false "enableviewstate =" false "%>
<! Doctype HTML public "-// W3C // dtd html 4.0 transitional // en">
<HTML>
<Head>
<Title> Products </title>
</Head>
<Body ms_positioning = "flowlayout">
<Form ID = "form1" method = "Post" runat = "server">
<Asp: DataGrid id = "datagrid1" runat = "server"> </ASP: DataGrid>
</Form>
</Body>
</Html>

The codebehind operated med the logic as follows:

Default. aspx. CS (excerpt)

Public class _ default: system. Web. UI. Page
{
Protected system. Web. UI. webcontrols. DataGrid datagrid1;
 
Private void page_load (Object sender, system. eventargs E)
{
Bindgrid ();
}

Private void bindgrid ()
{
Sqlconnection conn = new sqlconnection ("Server = localhost; database = northwind; Integrated Security = true ");
Sqldataadapter cmd = new sqldataadapter ("select * from products", Conn );
Dataset DS = new dataset ("Products ");
Cmd. Fill (DS );
Datagrid1.datasource = Ds;
Datagrid1.databind ();
}
...
}

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 "%>
<% @ Outputcache duration = "1" varybyparam = "NONE" %>
<! Doctype HTML public "-// W3C // dtd html 4.0 transitional // en">
<HTML>
<Head>
<Title> Products </title>
</Head>
<Body ms_positioning = "flowlayout">
<Form ID = "form1" method = "Post" runat = "server">
<Asp: DataGrid id = "datagrid1" runat = "server"> </ASP: DataGrid>
</Form>
</Body>
</Html>

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
ASP. NET apps v1.1.4322/requests/SEC/myapplication

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.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.