|One of the obvious ways to make something faster is to give it less to do (excepting, of course, that well known adage that if you want something done, give the task to a busy person). Caching is the prime method of speeding up a website and takes many forms: SQL server caches results, your data layer may cache results, your business objects may be cached, ASP.NET has a cache object, Appliction and Context objects, the session object, disk caching, your user controls and pages have output caching, there is server side caching within IIS, partial page caching, and client side caching within your browser itself.
Just to name a few.
Unfortunately your web.config file doesn't have an entry <caching level="11" for="everythingIncludingTheKitchenSink" />
Setting up caching requires attention to detail and an understanding of where the load is best relieved, what type of data synchronisation issues you may have (working in a webfarm?), what member you have, the length of time you wish to cache and your caching resources (memory).
For the last couple of weeks we've been focusing on the client side trying to understand what is causing the page to download slowly, and what we can do to speed up rendering. To this end the obvious fixes were to ensure IIS caching was enabled, and not just enabled, but enabled correctly.
IIS caching requires you to explicitly tell IIS that you want caching. Because, you know, you might enjoy having your readers download those images every...single...time. So you turn it on - ensuring you enable it for both static and dynamic content - and you find it works for your IIS6 servers but not your IIS7 servers (yes, we mix and match. We're crazy like that).
The trick is removing the eTag. Do a search and you will find the trick is actually setting the eTag changenumber to 0, which requires downloading the IIS Metabase editor, cranking it up, adding an arcane key and crossing your fingers. This then ensures that the eTag, a value that should be the same for a given version of a file on all servers, is the same. Change the file, the eTag changes, and the file is re-downloaded by the client and cached until it next changes.
However, the eTags between IIS6 and IIS7 differ so the only way to get around this is remove the eTags. An eTag is just an HTTP header so in IIS6 you just manually ask IIS6 to add a new header to the output stream called "eTag" with the value "". Voila, no eTags.
Except that this doesn't work for IIS7. People say it does, but it doesn't. You'll need to write a HttpModule to strip the output of the eTag manually.
You now have caching working. You've enabled it, set the expiry as a date in the far, far future, removed eTags if required, ensures static and dynamic are cached, and all is good. Speed skyrockets. Well, perceived speed.
However, you still have many readers who come once, and once only. Caching is no use for them. So the next step is compression.
Compressing your downloads (zips, images, HTML content itself) is again set by IIS but it's, yet again, a PITA in IIS6. I'm not going to go through the details - just do a search for "IIS compression metabase.xml" and you'll find the instructions for enabling compression properly on your servers.
And again you now have compression. You're sending small packages downstream, sending them less often, saving bandwidth, saving processor time, and everyone wins.
Just make sure you make copious notes of what you did, because when it comes time to adding a new server or repairing a failed server, you really don't want to go hunting around for all this stuff again.
Now where is that web.config setting we all need...
The Code Project | Co-founder
Microsoft C++ MVP