ASP.NET Scalability at WebDD

Thanks to everyone who attended my session on ASP.NET scalability at WebDD today - I hope you all found it useful. I got to the end of the section on caching, which is more or less the first half, and realised I had ten minutes left for the entire second half, so apologies for having to race through the rest of the slides. If anyone has any questions please feel free to post them in the comments here and I'll answer them.

I had a few questions afterwards over coffee, which were:
Q) Output Caching. Can you VaryBy things other than elements in the QueryString?
A) Yes, there are a range of VaryBy options: VaryByContentEncoding, VaryByControl, VaryByHeader, and VaryByCustom. In each case ultimately it boils down to a string. There's a discussion of all these options on MSDN, but basically VaryByContentEncoding's probably not going to help you too much since this looks at what encodings your browser can accept e.g. compressed content (and remember that I mentioned all the current browsers (and previous generation browsers) can accept compressed content). VaryByHeader looks at a semi-colon seperated list of HTTP headers. VaryByControl looks at the controls declared inside a UserControl. VaryByCustom is perhaps the most interesting as it allows you to roll your own scheme by implementing GetVaryByCustomString in your Global.asax file, or if you set it to 'browser' it caches page instances based on the browser name and major version.

Q) Is there a reason not to use VaryByParam=*?
A) VaryByParam=* will cache pages on all combinations of elements in the QueryString - I can only tell you what it does, it's up to you to decide whether this facility is going to fit into your application or not.

Q) Can you cache objects for longer than 20 minutes?
A) Yes. If you use sliding expiration, it takes a System.TimeSpan object. TimeSpan has three constructors - I used the hours/minutes/seconds constructor, but there's nothing to stop you using the second constructor which adds a days parameter onto the constructor. Bear in mind, however, that doing that means you're sacrificing that much memory on your server for that length of time. As with so many things in scalability, it's a trade-off...

Q) Do you need command-line access to your server to enable a SQL database for SQLCacheDependencies?
A) No. There's two options here: one is to keep in mind that the ASPNET_REGSQL command-line tool takes a server name from the -S parameter - this can be any SQL server that is on your network, you don't have to run the tool locally to the server you're enabling.
The second option is to use the SqlCacheDependencyAdmin static class, which gives you the ability to programmatically enable and disable databases and tables for cache dependencies.