I'll point out that if you have a CF(JRun) cluster set to use "non-sticky sessions" this will kill use of CF Graphing. AFAIK, there is no work around. Just an FYI
DK On 11/25/05, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > On 11/23/05, Dave Watts <[EMAIL PROTECTED]> wrote: > > > > > How do you span sessions across ColdFusion servers if you > > > > > aren't using Enterprise? > > > > > > > > You don't. > > > > > > Isn't it all a matter of how you cluster the machines though? > > > I mean, if you want to use sessions in a clustered environment, > > > you just need to make sure that your load balancer uses sticky > > > sessions. Basically, the goal is not to ever toss users between > > > servers, but just assign users to a server based on the load > > > balancing parameters when they first land on your site. > > > > If you do that, you aren't spanning sessions across CF servers. This > > approach is often referred to as "sticky sessions". If you use sticky > > sessions, you don't get failover, only load-balancing. This may or may not > > be acceptable, depending on your business needs and general server > > stability. > > Furthermore, you get a less powerful version of load-balancing -- > incoming initial user sessions are balanced according to load (or > whatever balancing scheme is being used) but once the user is *on* a > server, they're on it for the sessions (thus the "sticky"). So if a > server slows down b/c of a runaway process for example, *new* users > get balanced to the less loaded servers, but the folks on the server > with the slowdown are stuck. > > This is in contrast to active loadbalancing without sticky sessions > where the user gets the least loaded server (or whatever is set in the > balancing rubric) on *every* request. > > As an aside, implementing session-aware clustering can actually > degrade performance, even when done "right". Using files to store > session for example, is a common approach in both the LAMP stack and > RubyOnRails for scaling horizontally across N servers -- but your > chokepoint becomes the SAN or whatever storing the data. Even more > advanced solutions like memcached (eg LiveJournal and Slashdot) or > J2EE session clustering (eg CFMX) have problems b/c replicating data > between multiple nodes takes time when the data is very active. > > It's always a balance of reliability vs performance. > > -- > John Paul Ashenfelter > CTO/Transitionpoint > (blog) http://www.ashenfelter.com > (email) [EMAIL PROTECTED] > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225260 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
