As I said in a previous post I'm getting back into development..as part of this I've been playing around with the source of SubText, the likely future engine for this blog. Whilst doing this I found an interesting (and it seems fairly common) pattern when using an ASP.NET provider where to avoid the performance issues with Activator.CreateInstance the author places the first instance created in a static field then returns that as a singleton each time it's requested. This is great in terms of raw performance...but I have a bit of a problem with it...scalability. Actually this will apply to any Abstract Factory pattern implementation which uses a singleton as an object store).
The issue essentially boils down to the fact that by definition only one instance of the Provider class can now exist within the current appdomain...now you get it really quickly (as it's already instantiated) however it means you only ever use one DB connection (so kind of making Connection Pooling pointless) and of course if there's a long-running Db operation you have to wait until it completes for the next request to be processed. I should add that SubText uses output caching fairly heavily which does largely mitigate this issue for most requests at first, however as the blog and therefore the number of posts and users grows it's likely you have more requests for different bits of data; and so this data would be less likely to already have been cached so increasing concurrency becomes more and more likely.
The upshot of this is that you get a cutoff point where the use of the singleton in this case ceases offering a performance improvement and actually causes a performance decrease. My solution was fairly simplistic (and I haven't tested this for perf so...it's an assumption right now!); don't return the static instance, rather return a memberwise clone of the instance (I found this article after I did this but the results shown are consistent with what I expected). In essence I reduce the impact of object instantiation with this technique whilst providing a new instance for each call; thinking about it I should really cache this for each thread meaning I don't clone each time it's called...but rather for each new thread that's created...fairly easy to do by sticking it in the current web context (which does limit it to web apps...).
Anyhoo...just my little scalability obsession :-) Should get to bed, much speccing to do tomorrow :-(