The latest issue of MSDN Magazine has an article called “10 Tips for Writing High-Performance Web Applications”. Rob Howard gives the following tips for writing high-performance web applications:
- Return Multiple Resultsets
- Paged Data Access
- Connection Pooling
- ASP.NET Cache API
- Per-Request Caching
- Background Processing
- Page Output Caching and Proxy Servers
- Run IIS 6.0 (If Only for Kernel Caching)
- Use Gzip Compression
- Server Control View State
For more detailed information, don't forget about the Improving .NET Application Performance and Scalability Guide put out by the Microsoft Patterns and Practices group, which can be downloaded as a PDF.
All of the above are good recommendations, but I thought I would expand upon some of the ideas to provide the bigger picture.
Find You Chatty Interfaces
Many of Rob's suggestions deal with what I call Chatty Interfaces. As you build your design and data models, you will start to see a lot of frequent collaboration between certain classes and certain layers. The collaboration in some cases may have a significant performance impact, particularly if the collaboration is between resources that may reside on different physical tiers, such as web services on the Internet or a database server on a network.
When you notice these chatty interfaces and the significance in delay in the collaboration, you may want to replace the number of property gets and sets as well as frequent smaller method calls with a larger, more inclusive method call. Essentially you are reducing the number of round trips to satisfy your application needs.
You can spot the delays by tracing and profiling your application as well as looking at various performance counters in ASP.NET. I also like to reverse engineer my code into UML, in particular system sequence diagrams, that show me the collaboration between classes in my application. Armed with all that information, you can find bottlenecks in your application and increase the performance.
Premature Performance Optimization, Increased Complexity, and Higher Maintenance Effort
One of the things you may get caught up in when developing an ASP.NET web application is premature performance optimization, which is essentially optimizing your application based on unknown or non-existant performance requirements just for the sake of higher performance. Certainly higher performance is always good, but often it comes at a price of increased complexity and higher maintenance.
Rob mentions a couple of strategies that suggest complexity and higher maintenance: 1) stored procedures and 2) stored procedures that return multiple resultsets. I am not suggesting that stored procedures and multiple resultsets are rocket science, but maintaining them does increase the overall complexity and maintenance effort of the application.
Before jumping on those increasingly complex and higher to maintain performance optimization techniques, look at the simple ones first.
Cache as High Up in the Application Layers as Possible
Rob discusses several caching techniques briefly that are covered in more detail by him and other developers in other articles.
A good rule of thumb is to cache as high up in the application layers as possible, in particular the presentation layer. The page output caching features in ASP.NET are the absolute best place to cache in your application. If you learn no other caching techniques in ASP.NET, focus on the page output caching as this will give you the biggest bang for your buck in terms of performance and offers very little complexity.
If you have a page that has personal information about the user, consider partial page caching (fragment caching), where you break your page into controls and cache the generic sections of the page.
Good luck with caching. You can read more about the improved caching in ASP.NET 2.0.