Performance tuning can be tricky. It's especially tough in Internet-related projects with lots of components running around, like HTML client, HTTP network, Web server, middle-tier components, database components, resource-management components, TCP/IP networks, and database servers. Performance tuning depends on a lot of parameters and sometimes, by changing a single parameter, performance can increase drastically. This document lists out some tips for optimizing ASP.NET Web applications and many traps and pitfalls are discussed.
Tracing is one of the wonderful features which enables us to track the application's trace and the sequences. However, again it is useful only for developers and you can set this to "false" unless you require to monitor the trace logging.
false
Enabling tracing adds performance overhead and might expose private information, so it should be enabled only while an application is being actively analyzed.
When not needed, tracing can be turned off using:
<trace enabled="false" requestLimit=”10” pageoutput=”false” traceMode=”SortByTime” localOnly=”true”>
One extremely powerful feature of ASP.NET is its ability to store session state for users, such as a shopping cart on an e-commerce site or a browser history.
Since ASP.NET manages session state by default, you pay the cost in memory even if you don't use it, i.e., whether you store your data in-process or on state server or in a SQL database, session state requires memory and it's also time consuming when you store or retrieve data from it.
You may not require session state when your pages are static or when you do not need to store information captured in the page.
static
In such cases where you need not use session state, disable it on your web form using the directive:
<@%Page EnableSessionState="false"%>
In case you use the session state only to retrieve data from it and not to update it, make the session state read only by using the directive:
<@%Page EnableSessionState ="ReadOnly"%>
View state is a fancy name for ASP.NET storing some state data in a hidden input field inside the generated page. When the page is posted back to the server, the server can parse, validate, and apply this view state data back to the page's tree of controls.
View state is a very powerful capability since it allows state to be persisted with the client and it requires no cookies or server memory to save this state. Many ASP.NET server controls use view state to persist settings made during interactions with elements on the page, for example, saving the current page that is being displayed when paging through data.
DataGrid
Pages that do not have any server postback events can have the view state turned off.
The default behavior of the ViewState property is enabled, but if you don't need it, you can turn it off at the control or page level. Within a control, simply set the EnableViewState property to false, or set it globally within the page using this setting:
ViewState
EnableViewState
<%@ Page EnableViewState="false" %>
If you turn view state off for a page or control, make sure you thoroughly test your pages to verify that they continue to function correctly.
When you create the application, by default this attribute is set to "true" which is very useful while developing. However, when you are deploying your application, always set it to "false".
true
Setting it to "true" requires the PDB information to be inserted into the file and this results in a comparatively larger file and hence processing will be slow.
Therefore, always set debug="false" before deployment.
debug="false"
Response.Redirect() method simply tells the browser to visit another page.
Response.Redirect()
Redirects are also very chatty. They should only be used when you are transferring people to another physical web server.
For any transfers within your server, use .transfer! You will save a lot of needless HTTP requests. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
.transfer
Response.Redirect
Server.Transfer
5. A) To reduce CLR Exceptions count, use Response.Redirect (".aspx", false) instead of response.redirect (".aspx").
Response.Redirect (".aspx", false)
response.redirect (".aspx")
String is Evil when you want to append and concatenate text to your string. All the activities you do to the string are stored in the memory as separate references and it must be avoided as much as possible.
String
string
i.e. When a string is modified, the run time will create a new string and return it, leaving the original to be garbage collected. Most of the time, this is a fast and simple way to do it, but when a string is being modified repeatedly, it begins to be a burden on performance: all of those allocations eventually get expensive.
Use String Builder whenever string concatenation is needed so that it only stores the value in the original string and no additional reference is created.
Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications.
You can use as many try/catch blocks as you want. Using exceptions gratuitously is where you lose performance. For example, you should stay away from things like using exceptions for control flow.
try
catch
finally
Try
Catch
User Input is Evil and it must be thoroughly validated before processing to avoid overhead and possible injections to your applications.
Client site validation can help reduce round trips that are required to process user's request. In ASP.NET, you can also use client side controls to validate user input. However, do a check at the Server side too to avoid the infamous JavaScript disabled scenarios.
Round trips significantly affect performance. They are subject to network latency and to downstream server latency. Many data-driven Web sites heavily access the database for every user request. While connection pooling helps, the increased network traffic and processing load on the database server can adversely affect performance.
Make sure you don't execute code needlessly. Use Page.ISPostBack property to ensure that you only perform page initialization logic when a page is first time loaded and not in response to client postbacks.
Page.ISPostBack
Explicitly using return allows the JIT to perform slightly more optimizations. Without a return statement, each function/method is given several local variables on stack to transparently support returning values without the keyword. Keeping these around makes it harder for the JIT to optimize, and can impact the performance of your code. Look through your functions/methods and insert return as needed. It doesn't change the semantics of the code at all, and it can help you get more speed from your application.
return
Foreach is far more readable, and in the future it will become as fast as a For loop for special cases like strings. Unless string manipulation is a real performance hog for you, the slightly messier code may not be worth it.
Foreach
For
When you use byRef, you pass pointers instead of the actual object.
byRef
Many times, this makes sense (side-effecting functions, for example), but you don't always need it. Passing pointers results in more indirection, which is slower than accessing a value that is on the stack.
When you don't need to go through the heap, it is best to avoid it there by avoiding indirection.
An ArrayList has everything that is good about an array PLUS automatic sizing, Add, Insert, Remove, Sort, Binary Search. All these great helper methods are added when implementing the IList interface.
ArrayList
IList
The downside of an ArrayList is the need to cast objects upon retrieval.
Always make sure you check Page.IsValid before processing your forms when using Validator Controls.
Page.IsValid
Take advantage of paging's simplicity in .NET. Only show small subsets of data at a time, allowing the page to load faster.
Just be careful when you mix in caching. Don't cache all the data in the grid.
ASP.NET allows you to cache entire pages, fragment of pages or controls. You can also cache variable data by specifying the parameters on which the data depends. By using caching, you help ASP.NET engine to return data for repeated request for the same page much faster.
A proper use and fine tune of caching approach will result in better performance and scalability of your site. However, improper use of caching will actually slow down and consume lots of your server performance and memory usage.
Good candidate to use caching is if you have infrequent chance of data or static content of web page.
Authentication can also have an impact over the performance of your application. For example, passport authentication is slower than form-base authentication which in here turn is slower than Windows authentication.
The use of web server controls increases the response time of your application because they need time to be processed on the server side before they are rendered on the client side.
One way to minimize the number of web server controls is by taking into consideration, the usage of HTML elements where they are suited, for example if you want to display static text.
Calls to unmanaged code are a costly marshaling operation.
Try to reduce the number calls between the managed and unmanaged code. Consider doing more work in each call rather than making frequent calls to do small tasks.
If you are working with distributed applications, this involves additional overhead negotiating network and application level protocols. In this case, network speed can also be a bottleneck. Try to do as much work as possible in fewer calls over the network.
Use simple structs when you can, and when you don't do a lot of boxing and unboxing.
struct
ValueTypes are far less flexible than Objects, and end up hurting performance if used incorrectly. You need to be very careful about when you treat them like objects. This adds extra boxing and unboxing overhead to your program, and can end up costing you more than it would if you had stuck with objects.
ValueTypes
Objects
Minimize the number of assemblies you use to keep your working set small. If you load an entire assembly just to use one method, you're paying a tremendous cost for very little benefit. See if you can duplicate that method's functionality using code that you already have loaded.
By default, ASP.NET comes configured to encode requests and responses as UTF-8.
If ASCII is all your application needs, eliminating the UTF overhead can give you back a few cycles. Note that this can only be done on a per-application basis.
These are general things to adopt in any programming language, which consume lot of memory. Always avoid Nested Loops, Recursive functions, to improve performance.
When you can, use toString() instead of format(). In most cases, it will provide you with the functionality you need, with much less overhead.
toString()
format()
Web developers who care about performance want browser to load whatever content it has as soon as possible. This fact is especially important for pages with a lot of content and for users with slow Internet connections. When the browser loads the page progressively the header, the logo, the navigation components serve as visual feedback for the user.
When we place style sheets near the bottom part of the HTML, most browsers stop rendering to avoid redrawing elements of the page if their styles change thus decreasing the performance of the page. So, always place StyleSheets into the Header.
StyleSheets
Header
Unlike StyleSheets, it is better to place scripts to the end of the document. Progressive rendering is blocked until all StyleSheets have been downloaded. Scripts cause progressive rendering to stop for all content below the script until it is fully loaded. Moreover, while downloading a script, the browser does not start any other component downloads, even on different hostnames.
So, always have scripts at the end of the document.
Using external files generally produces faster pages because the JavaScript and CSS files are cached by the browser. Inline JavaScript and CSS increase the HTML document size but reduce the number of HTTP requests. With cached external files, the size of the HTML is kept small without increasing the number of HTTP requests thus improving the performance.
Return Multiple Resultsets
If the database code has request paths that go to the database more than once, then these round-trips decrease the number of requests per second your application can serve.
Return multiple resultsets in a single database request, so that you can cut the total time spent communicating with the database. You'll be making your system more scalable, too, as you'll cut down on the work the database server is doing managing requests.
Connection Pooling and Object Pooling
Connection pooling is a useful way to reuse connections for multiple requests, rather than paying the overhead of opening and closing a connection for each request. It's done implicitly, but you get one pool per unique connection string. Make sure you call Close or Dispose on a connection as soon as possible. When pooling is enabled, calling Close or Dispose returns the connection to the pool instead of closing the underlying database connection.
Close
Dispose
Account for the following issues when pooling is a part of your design:
Use SqlDataReader Instead of Dataset wherever it is possible
If you are reading a table sequentially, you should use the DataReader rather than DataSet. DataReader object creates a read only stream of data that will increase your application performance because only one row is in memory at a time.
DataReader
DataSet
Remember that the dataset stores all of its data in memory, and that the more data you request, the longer it will take to transmit across the wire.
dataset
Therefore, only put the records you need into the dataset.
Queries that process and then return more columns or rows than necessary waste processing cycles that could best be used for servicing other requests.
SELECT *
WHERE
Keep round trips to an absolute minimum.
Connections are an expensive and scarce resource, which should be shared between callers by using connection pooling. Opening a connection for each caller limits scalability.
To ensure the efficient use of connection pooling, avoid keeping connections open and avoid varying connection strings.
If you select the wrong type of transaction management, you may add latency to each operation. Additionally, if you keep transactions active for long periods of time, the active transactions may cause resource pressure.
Transactions are necessary to ensure the integrity of your data, but you need to ensure that you use the appropriate type of transaction for the shortest duration possible and only where necessary.
Over Normalized tables may require excessive joins for simple operations. These additional steps may significantly affect the performance and scalability of your application, especially as the number of users and requests increases.
Dataset serialization is more efficiently implemented in .NET Framework version 1.1 than in version 1.0. However, Dataset serialization often introduces performance bottlenecks.
Dataset
You can reduce the performance impact in a number of ways:
DataTable
CommandBuilder objects such as SqlCommandBuilder and OleDbCommandBuilder are useful when you are designing and prototyping your application. However, you should not use them in production applications. The processing required to generate the commands affects performance.
CommandBuilder
SqlCommandBuilder
OleDbCommandBuilder
Manually create stored procedures for your commands, or use the Visual Studio® .NET design-time wizard and customize them later if necessary.
CommandType.StoredProcedure
CommandType.Text
When using a data adapter, avoid auto-generated commands. These require additional trips to the server to retrieve meta data, and give you a lower level of interaction control. While using auto-generated commands is convenient, it's worth the effort to do it yourself in performance-critical applications.
With a data reader, use CommandBehavior.SequentialAccess. This is essential for dealing with blob data types since it allows data to be read off of the wire in small chunks. While you can only work with one piece of the data at a time, the latency for loading a large data type disappears. If you don't need to work the whole object at once, using Sequential Access will give you much better performance.
CommandBehavior.SequentialAccess
Enable Option Strict and Option Explicit for your pages
With Option Strict on, you protect yourself from inadvertent late binding and enforce a higher level of coding discipline.
Use early binding in Visual Basic or JScript code
Visual Basic 6 does a lot of work under the hood to support casting of objects, and many programmers aren't even aware of it. In Visual Basic 7, this is an area out of which you can squeeze a lot of performance.
When you compile, use early binding. This tells the compiler to insert a Type Coercion is only done when explicitly mentioned.
This has two major effects:
Put Concatenations in One Expression
If you have multiple concatenations on multiple lines, try to stick them all on one expression. The compiler can optimize by modifying the string in place, providing a speed and memory boost. If the statements are split into multiple lines, the Visual Basic compiler will not generate the Microsoft Intermediate Language (MSIL) to allow in-place concatenation.
When we talk about ASP.NET performance, there are lots of factors in place. Discussed above are the most critical of the speed improvements you can make in ASP.NET that will have a dramatic impact on the user experience of your web application.
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
General News Suggestion Question Bug Answer Joke Rant Admin
Math Primers for Programmers
Submit an article or tip
Post your Blog
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
