In theory memory is cheap and fast, but data staleness becomes an issue very fast unless your data is very static (and if it were, why is it in a DB at all?). Caching data is an important idea but the level of cache is important to figure out. I think you might find that using the DB but using page and control caching to help a lot more than building a magic infrastructure to cache the entire db.
Thanks, Shawn Wildermuth http://adoguy.com http://wildermuthconsulting.com Microsoft MVP (C#), MCSD.NET, Author and Speaker The Silverlight Tour is coming to a city near you! -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Miika Makinen Sent: Saturday, February 09, 2008 12:47 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] Scaling Web Applications Hi all, We are running a set of web applications that are getting more and more popular. Of course this means that our current hardware is just not enough. I had this idea that to really be scalable, we should have *everything* in RAM (which is cheap) and use a DB just for permanent storage (disks can be very very slow). When any data is accessed it is first checked from RAM cache and only if it does not already exist there will the db be used (any subsequent calls would then use the cached data). Updating would just update the cache and it could even be a separate async/idle process to persist that cache into db. How does this kind of idea sound? And more importantly, where to begin? Are there any frameworks that could make this kind of application development easier? Any comments appreciated, Miika =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
