From: Monsur Hossain [mailto:[EMAIL PROTECTED]] wrote:
> I've been reading a lot of resources[1][2] advocating the use > of ASP.NET's Application object to store a global data cache. > This limits hits to the database. However I'm skeptical of > the Application object's ability to scale to larger sites > with over a million page views a day. In our current web > application (using just ASP), we've made it a rule not to use > Application/Sessions in order to gain that tiny performance > edge. Anyone have any facts/opinions regarding .NET's > Application object as a data cache? Anyone have a better way? Well the HttpApplication::Application property is just an instance of type HttpApplicationState which is derived from NameObjectCollectionBase which has an implementations that uses a HashTable for key/value management. Values are also stored in an ArrayList for sequential indexed access. So really, the performance is as good as the combined implementation of those two types. If you don't need sequential access, which most people don't, you could do better by using just a hashtable directly. Now... that's just talking about raw CPU of course and the standard debate is usually memory. I think applications that are being designed from the ground up today around ASP.NET would be better served using the new caching architecture (HttpContext::Cache et al). This allows you to have only the data that's truly in demand stuck in memory and let the architecture handle the details of caching. HTH, Drew You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
