Speed Up Your ASP.NET Pages (Continued)

3) Utilize the HttpServerUtility.Transfer method
The .NET Framework's vastness might obscure access to classes or methods that improve upon familiar techniques. For example, you probably use the Server object's Request method when you want to redirect page execution from the running page to another page. But you'll do yourself a favor if you switch to the HttpServerUtility class's Transfer method for redirection within the content of the current site. Using this method eliminates unnecessary client/server round trips and improves site performance appreciably. Even the fastest execution on the server amounts to spinning your wheels if you're constantly pushing data over the wire at the same time.

This wheelspinning happens all too frequently with data validation, where overzealous use of server-side validation produces constant communication with the client. You're better off performing validation in script on the client when you can, rather than passing the work back to the server. Obviously, you must return to the server to validate some things, but do work on the client when you can and save the round trip.

4) Don't Overdo a Good Thing
Save View State Only When Necessary.
Server-side controls save view state by default. Inspect your Web pages' source code and you'll see why this behavior can hamper performance. Textboxes and other simple controls don't impose much overhead in the view state. More complex controls are another matter. For example, a data grid might send a 10K block of Base-64-encoded text back and forth between the client and server (see Figure 1). That's not a problem if it's going over a high-speed network, but users connected over a 56K modem might think your Web site is a real slug while this invisible conversation is going on.

Don't Rely on Exceptions.
Exceptions are good and useful, but they're costly. Every exception raised in a Windows application produces a noticeable delay in execution. Don't make the common mistake of using exceptions to pass information from one routine to the next with queries such as, "Did the method succeed or fail?" Nor should you signify that a message needs to be reported in a dialog. Use language constructs such as if/else statements if you want to alter the execution flow of your application. The overhead required to unwind a call stack and perform an exception notification vastly exceeds the overhead needed to make a change in the program's execution path.

Your exception-based code can impact the server as well—the same server that might be busy running requests from other sites and that is most likely being pushed a lot harder than a desktop system. Your application's exception-based delays on the server might not be as obvious as those on a Windows app, but they still contribute to users' perception of the performance of your application on their desktops.

Restrict Use of Session State.
Session state is another of the .NET Framework's great built-in features, but turn it off wherever you can. This feature is turned on by default—and like exceptions, it isn't free. You pay a maintenance overhead and subsequent performance cost for supporting a page's session state. Avoid this cost either by using page directives to disable the state for a page completely or by making the pages' access to session state read-only:

<%@ Page EnableSessionState="false" %>
<%@ Page EnableSessionState="readonly" %>

Disable session state completely through the site's configuration file when your entire site doesn't need it:

<sessionState mode="off" />.

It gets more complicated when you do need session state in some places. This snippet of a configuration file shows how you can store it as in-process session state:

<sessionState
        mode="InProc"
stateConnectionString="tcpip=127.0.0.1:4
2424"
        sqlConnectionString="data 
source=127.0.0.1;Trusted_Connection=yes"
        cookieless="false" 
        timeout="20" 
/>

You can also store session state as out-of-process session state, either as a Windows service or in a SQL Server database. You'll get the most application speed by storing it in-process. On the other hand, out-of-process options work best sometimes. Have fun choosing the best set of trade-offs for your situation.