Perrin Harkins wrote: > On Tue, 2006-05-09 at 17:12 +0000, E.Q. McGoon wrote: > > Certainly, but I'm struggling with the "big picture" so to speak. > > How to plan a session handling strategy that will grow with the > > application as more hardware is added to accommodate growing usage. > > Why is this any different from your general database strategy? If the > database can't handle the load, having sessions still working is > useless.
> Strategies for scaling databases are widely discussed. The basic > progression is from one big database to one write database and several > replicated read databases and then to partitioned data (e.g. users A-H > on this database, I-N on another, etc.). Now I'm starting to see where my mental blocks are. I've always operated under the notion that sessions are best left to the operating system on each node, so to speak, in an effort to reduce db traffic. > You might be interested in this series of blog posts by Tim O'Reilly > on the subject: > http://radar.oreilly.com/archives/2006/05/brian_aker_of_mysql_responds > .html I will read this. Thanks for your feedback. --
