web application performance tips(asp.net)

I am a student of computer science at this time i am trying to write down some tips for web application performance boast, For this i have collected some data from microsoft articles, wrox professional Asp.net performance book etc and from my personal experiences.I must highly appreciate your comments, corrections and additions.------------------------------------------------------------------------------------------------
Tips
1-Review your database code to see if you have request paths that go to the database more than once. Each of those round-trips decreases the number of requests per second your application can serve. By returning multiple resultsets in a single database request, you can cut the total time spent communicating with the database. You'll be making your system more scalable, too, as you'll cut down on the work the database server is doing managing requests.

2-The ASP.NET DataGrid exposes a wonderful capability: data paging support. When paging is enabled in the DataGrid, a fixed number of records is shown at a time. Additionally, paging UI is also shown at the bottom of the DataGrid for navigating through the records. The paging UI allows you to navigate backwards and forwards through displayed data, displaying a fixed number of records at a time.one that i want to mention in this respect is, in this case your datagrid will be bound to all result set what if client needs only 10% data of this result set??? so in this case i would like to recomend little bit different approach that can be done with the help of stored procedure. i just want to suggest that you must return the actual number of records that are needed and size and there correct calculation beacuse it can be displayed correctly on client side.

3- In ideal scanario of application dployment whenver your data layer is seprately working on data server, effective connection pooling can increase your performance.

4- Effective caching can greatly increase your application performance but if it is not done intelligently than it is so harmful for your application like out of memory exception etc. There are several rules for caching data. First, if data can be used more than once it's a good candidate for caching. Second, if data is general rather than specific to a given request or user, it's a great candidate for the cache. If the data is user- or request-specific, but is long lived, it can still be cached, but may not be used as frequently. Third, an often overlooked rule is that sometimes you can cache too much that can create an out-of-memory error. Therefore, caching should be bounded. There are a several great features of the Cache that you need to know. The first is that the Cache implements a least-recently-used algorithm, allowing ASP.NET to force a Cache purge—automatically removing unused items from the Cache—if memory is running low. Secondly, the Cache supports expiration dependencies that can force invalidation. These include time, key, and file. Time is often used, but with ASP.NET 2.0 a new and more powerful invalidation type is being introduced: database cache invalidation. This refers to the automatic removal of entries in the cache when data in the database changes.

5- Per request cache is also very good option in some cases, small improvements to frequently traversed code paths can lead to big, overall performance gains. This can be done in asp.net by using HttpContext.Items.

6- you can achive performance gains by using worker threads in case of heavy processing.

7- If you have an ASP.NET page that generates output, whether HTML, XML, images, or any other data, and you run this code on each request and it generates the same output, you have a great candidate for page output caching. By simply adding this line to the top of your page . At this point i do agree that page out put cache does not make your application more efficient but it can reduce burden on servers.

8- There are a number of drawbacks to the use of view state, however. First of all, it increases the total payload of the page both when served and when requested. There is also an additional overhead incurred when serializing or deserializing view state data that is posted back to the server. Lastly, view state increases the memory allocations on the server. Several server controls, the most well known of which is the DataGrid, tend to make excessive use of view state, even in cases where it is not needed. The default behavior of the ViewState property is enabled, but if you don't need it, you can turn it off at the control or page level. Within a control, you simply set the EnableViewState property to false, or you can set it globally within the page using this setting: If you are not doing postbacks in a page or are always regenerating the controls on a page on each request, you should disable view state at the page level.