Jeffrey made a good comment on my previous post, Developing High Performance and Scalable ASP.NET Websites, concerning developers that try and squeeze every last drop of performance from their code, but fail to look at the "out-of-process" calls that tend to be inherently slow. In his comment, Jeffrey is thinking mainly about calls to the Database, which typically sits at a different tier than your ASP.NET web application. Since it sits at a different tier, there is lag time associated with messaging back and forth to persist and retrieve information from the repository.
Rule of Thumb: Avoid Chatty Interfaces Between the Tiers in Your Application
A general rule of thumb concerning calls between tiers (or layers that could one day be separated into tiers) is to avoid chatty interfaces between the tiers in your application.
Calls between tiers are migrating over various networks and contending with other clients that are also trying to consume resources. Each user story of your application may need various resources / data across another tier. The less roundtrips and calls you have across that tier in order to satisfy the needs of the client, the more performant and scalable your web application tends to be.
Think About Your User Interface
This is why I mentioned the idea of understanding the needs of the user interface in the previous post. The less a client requests information from your website, the more HTTP requests your website or web application can handle as a whole. The most sought after information can be grouped accordingly and wisely on your pages so that it eliminates the need for your visitors to have to browse and drill-down to information they want the most.
In addition, using output caching on your ASP.NET pages not only short circuits the request on the web server, but also sends HTTP headers back to the browser and / or proxy server suggesting they can cache these pages for a particular length of time. This caching in the browser and proxy server avoids chatty calls between the client and IIS tiers for information that is relatively unchanged.
Interacting With The Database
Just as with your UI, you want to avoid a lot of roundtrips to and from the database to satisfy a user story. Typically this is pulled off in 1 of 2 ways or both:
- Caching
- Returning multiple resultsets in a single call
Caching in this case doesn't refer to output caching at the UI layer, but usually the Cache Object or In-Process Session State in ASP.NET. You can use these objects to store database data that is both frequently requested and relatively static to avoid future calls to the database. Saving an object in the Cache is as simple as Cache.Insert("MyObject", myObject). Before making the call to the database for the information, you would first check the Cache Object and return the information from there if it exists.
Returning multiple resultsets is fairly common when you need data across several tables in your database. As opposed to making several database calls to get data from each and every table, you return either a DataSet or several resultsets via a DataReader in a single call.
Focus on Maintainability
Inevitably, as you start performance tuning and trying to avoid chatty calls between the tiers, the application tends to become more complex and less maintainable. The key is to strike a good balance and avoid any premature optimization that is not based on requirements. If you plan on keeping this application around for awhile, you will want to err on the side of ease of maintenance. Try to avoid chatty interfaces, but introduce additional complexity only to address performance issues based on realistic and actual performance requirements.
Conclusion
When developing your web applications, pay close attention to the communication between various tiers. In general, you want to avoid chatty interfaces between those tiers in order to make your web application as performant and scalable as possible. This performance tuning tends to impact the maintainability of your application, so strike a good balance between the two that is based on actual customer requirements.