|
Optimize ASP.NET Performance
Take advantage of these performance tips, and make your ASP.NET applications fly whether you use version 1.1 or 2.0.
by Peter Vogel
November 18, 2005
Technology Toolbox: Visual Basic, ASP.NET
It's axiomatic that everyone wants to create applications that run faster and use less memory. In an ideal world, the best thing to do is to sit down and take the time to rearchitect your application so it meets your performance goals. Rarely is the best approach implementing a series of minor tweaks to fix performance bottlenecks you discover after you've written the application.
In the real world, though, you often find yourself tracking down performance bottlenecks and coding minor tweaks to address them. I'll give you some easy-to-implement tips that can help you address some common coding performance problems in your ASP.NET applications. Some of these tips will help you avoid the problem in the first place, whereas others might help you find and fix a problem after you see it. Nothing is free, unfortunately, and most of these tips come with some kind of trade-off. Sometimes that trade-off is memory for speed (or vice versa), and sometimes that trade-off is accepting that your program behaves differently. Sometimes rearchitecting your application doesn't seem like such a bad idea after all.
One of the most important things you can do to improve performance in an ASP.NET application is to reduce the number of round trips to the server. Don't request the current page if you don't have any processing to perform on the server before transferring the user to another page. For example, I once had a client whose most frequently used button on the most frequently used page contained a single line of code that did exactly one thing: It redirected the user to the next page. In this circumstance, you can dispense with the button and simply add a Hyperlink control to the page that causes the browser to request the next page directly. Your server will have one less page to process.
Sometimes you use a button and a line of code because the next page needs some data from the current page. In ASP.NET 2.0, however, you can avoid requesting the current page and post the current page's data to the server by using cross-page posting. All you have to do is set the PostBackUrl property of your button to the URL of the next page. On the new page, use the PreviousPage property to retrieve the data you need from the current page. This code retrieves the value of a control called FirstNameTextBox from the previous page:
Dim Name As String
Name = CType(Me.PreviousPage.FindControl( _
"FirstNameTextBox"), TextBox).Text
You also can reduce the overhead of transferring the user from one page to another. If your user doesn't need to bookmark a page, use the Transfer method of the Server object to send the user a new page instead of the Redirect method of the Response object. The Redirect method requires two round-trips to the server to get the user to the next page. The Transfer method simply sends the user to the new page, eliminating the overhead of a second request to the server (see Figure 1).
Note that there is a usability cost to employing the Transfer method. You can use the Transfer method only to send the user to a page in the same site. More importantly, the browser doesn't see the switch in pages, so the address bar of the browser reflects the URL of the original page. This can cause a complication when bookmarking the page because the user is actually bookmarking the page you transferred the user from, rather than the page the user sees. Similarly, a user refreshing the page is requesting a new version of the page specified in the address box, rather than the displayed page.
Reduce the Server's Load
It's obvious, but the less work you do on the server, the faster your server will run. Unless you take advantage of some server-side feature of a control, you should consider using the equivalent HTML control for any server-side code. For instance, do the labels on your page need to be ASP.NET server-side labels? If not, use the HTML Label control, which requires considerably less processing on the server. If all you use the DataGrid control for is to display data, you should look at switching to a Table control. You can avoid all the overhead of the DataGrid for the cost of a few lines of code to generate the rows and columns for your data. Faster yet, you can write the Table tags yourself and use a Literal control to display your HTML. It's more work for you at design time, but less work for your server on every request for the page at run time.
The more processing that you do on the client with client-side code, the less processing you'll have to do on the server. ASP.NET 1.1 includes several methods for adding client-side code to your page dynamically. In ASP.NET 2.0, the tools are expanded to make it even easier to insert JavaScript into your page. Visual Studio 2005 also provides better support for client-side programming. Setting the GridView's EnableSortingandPagingCallbacks property (or the DetailView's EnablePagingCallbacks property) causes all sorting and paging to be performed on the client rather than on the server.
Back to top
|