In December I presented several pratical ways to optimize your ASP.NET site for better performance at the main TRINUG meeting. I want to start presenting those thoughts in my blog in a series of entries. Hopefully I will be able to expand upon those ideas I presented and add to them. As with all things I have learned several new tricks, plus there are new items that ASP.NET 2.0 offers that will benefit all of us as we update our projects.
The first thing is to determine where you can have bottlenecks in the website chain. At a very high level you need to isolate your application into 4 areas.
- Hardware and File I/O
- Business Logic
In my presenatation I had Hardware and File I/O separated and did not include business logic. The more I think about it File I/O and Hardware can be one, but you must realize there are software means of increasing your I/O performance in ASP.NET, primarily caching.
First let me cover aspects of your database that can affect your application. I think we can all agree that a properly normalized database will ensure your data is organized in a efficient manner. Second, and I can not stress this enough, use stored procedures to provide interaction from your web site to the data. I think these two are no brainers for most, so I will not cover them.
Return only the data you know you will need. Lets take a product catalog for example. All books and tutorials on displaying a product catalog usually give us something like this for a select statement:
Select * from Products
Well that is great when you have 10 products, 6 fields and little traffic. Now let's extrapolate that to 15,000 products, 100 fields (5 of which are calculated at the time of selection) and thousands of visitors per day. We have ourselves a slugish nightmare.
In this situation, look at where you are presenting a list of data and write a select statement that only returns the fields that will be visible to the user. Also reduce the number of user defined functions you call to a few as possible.
Now I knwo this is probably obvious, but how often have you thought about creating some variation of the following stored procedure list:
Breaking out your calls like this can drastically increase your performance. Of course you should also look at ways to Cache the data in memory to avoid calling the stored procedure as much as possible. I will cover caching choices in future entries.
In my next entry I will review choises for hardware architecture. The bigger, the better.