Fixing Four ASP.NET Performance Bottlenecks

Fixing Four ASP.NET Performance Bottlenecks

ASP.NET has become developers’ foremost choice in developing high traffic web applications. Because of its scalable nature, ASP.NET application tier can seamlessly handle thousands of concurrent users with their millions of requests per day. Such high traffic ASP.NET applications are deployed in a load balanced web farm with a load balancer routing user requests to multiple web servers.

While the ASP.NET application tier performs exceptionally well even during high transactional loads, the application faces some serious scalability bottlenecks in other areas. This causes your ASP.NET application to slow down and it may even halt just when your business activity is at its peak.

The Problem: Four Performance Bottlenecks

These four performance bottlenecks are described below:

Figure 1: Four Performance Bottlenecks in ASP.NET Applications

Database Bottleneck

In a load-balanced web farm scenario when your transaction load increases, you can easily add more web servers to scale linearly but you cannot add more database servers to the database tier (SQL Server, Oracle, others) in the same fashion. So, the database starts to slow down and may even crash at one point. This is the most serious performance bottleneck that your application faces.

ASP.NET Session State Storage Bottleneck

ASP.NET Session State has to be stored somewhere and its storage also becomes a bottleneck just like the application database. There are three storage options provided out of the box by Microsoft, namely InProc, State Server, and SQL Server. All three have performance bottlenecks.

InProc forces you to use a single worker process per web server, which does not work in a multi-processor or a multicore environment, where having multiple worker processes is preferred. And, in a load-balanced web farm, a sticky session bit is required on the load balancer for always sending user requests to the web server where the session was created, even if this web server is overloaded and other web servers are free.

Also, SQL Server is not an ideal store for ASP.NET session state because it stores them as BLOBs and SQL Server was not designed for BLOB storage and doesn’t perform well with it.

ASP.NET View State Bottleneck

ASP.NET View State is a client-side state management feature that gets constructed on the web server for keeping the data of controls such as buttons and drop downs. This data is sent to the browser only to return back when a postback occurs. And, an ASP.NET View State string can easily be 100’s of KBs in size, multiplied by millions of requests you receive each day.

This not only slows down the response time of your ASP.NET application but also consumes a lot of extra bandwidth. And, as you know, bandwidth is not free and this can significantly increase your operational cost as well. 

Needless Page Execution

Many times, ASP.NET page output does not change across multiple requests because the underlying data didn’t change. But, the page is still executed to produce the same output as last time. This extra page execution consumes a lot of system resources like memory and CPU and also makes database calls.

The Solution: In-Memory Distributed Cache

The most appropriate solution to all these bottlenecks is to incorporate an In-Memory Distributed Cache in your ASP.NET application. NCache is a popular Open Source distributed cache for .NET. Let’s quickly discuss how to fix our four performance bottlenecks with NCache.

Application Data Caching

NCache allows you to cache your application data (both read-only reference data and frequently changing transactional data) so you can reduce those expensive database trips. Instead of going to the database, NCache routes approximately 85-90% of your requests to the cache. This rules out the chances of any database contention.

Unlike a database, NCache never becomes a bottleneck because it is a distributed cache and it scales linearly just like your application tier. NCache builds a cluster of cache servers and allows you to add more servers to the cluster as your transaction load increases. Here’s a sample code that fetches the data from the database and stores it in the cache cluster (If it is not already present in the cache).

Session State Storage Configuration

NCache also lets you store your ASP.NET Sessions in the cache. This is a much faster in-memory store than your other storage options. And, to provide reliability, NCache replicates your sessions at multiple servers so, in case of a server crash, no session data is lost.

The nice thing about ASP.NET Session State storage in NCache is that there is no programming effort and you can plug it in seamlessly through a web.config change. Below is an example.

View State Configuration

NCache lets you cache your ASP.NET View State on the web server end by sending only a small identifier key to the browser. While returning in a postback, this small identifier key is used by NCache to fetch the ViewState results by intercepting it through its HTTPHandler. This View State is then delivered to your ASP.NET page.

The net result is a much faster ASP.NET application with a much smaller bandwidth footprint. Below is a config change example of how to use NCache for caching ASP.NET View State:

ASP.NET Output Cache

In order to prevent the needless execution of ASP.NET pages when their output doesn’t change, ASP.NET provides an Output Cache framework for single server and single worker process configurations. NCache, on the other hand, extends it for multi-server and multiple worker processes configurations.

Through NCache, you can also expect your pages to expire when their related data is modified in the database. Below is an example.


Leave a Reply

Your email address will not be published. Required fields are marked *