Tuning ASP.NET Performance

Performance work is often neglected until it dramatically surfaces as a major blocking issue. Do not wait until deployment to discover the performance characteristics of an application. Performance tuning is best handled as an iterative process where the biggest gains can often be had easily at first. You should understand the reasons behind the time-to-first-byte and time-to-last-byte numbers for the most frequently accessed pages of an application. Output caching and data caching can enhance the speed and efficiency of your application more than code changes alone.

• When simulating real-world load, use various pseudo-random user- agent strings and completely random requests with large query strings and quantities of posted data. Live servers must endure this type of load, so accurate analysis should include malformed requests along with the valid ones.

• The time-to-first-byte throughput metric translates directly into how the user perceives the performance of the Web application. Even when throughput numbers look adequate, the user might feel that the response time is inadequate. The user is not concerned with how many requests the server can manage; she just notices how fast her request is handled.

• Become proficient at using the load generating tool you choose. This might seem like obvious advice, but we can’t emphasize it enough. Almost all test packages include various parameters that can be customized to vary the mix of client connection speeds, SSL connections, user-agents, and security credentials. To effectively utilize the tool and thus measure Web application performance accurately, you must understand how to vary the settings in accordance with your application requirements.

• Keep batch compilation enabled, but make requests to each Web application while bringing a site online so that the first user to issue a request to the site does not see the delay of batch compilation, and the whole directory can be batch compiled.

• Store application-wide data in the cache object instead of the application object. The cache object does not have the same locking semantics and provides more flexibility.

• Do not create COM objects in a page constructor, either explicitly or by declaring the object as a page-scoped variable. If you must use legacy COM objects, create them when they are needed and release them as soon as you are done with them.