On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > "Stuart Dallas" <stuart@xxxxxxxx> schrieb: > > > On Friday, 18 March 2011 at 16:19, Torsten Rosenberger wrote: > > Hello > > > > > > First you need to decide which type of cluster you choose. If you use LVS you can tell the director do bind one client to one server so you do not need to replicat session. > > > > As I said in my response to Tedd, binding clients to servers can cause problems because you might end up with a bunch of resource-intensive users being locked to a single server when other servers are sitting there practically idle. Load balancers perform best when they are not restricted in this way. > > > > > If you choose DNS for load balancing you should replicat the session by database or DRBD or memcache server. Also transfer the session id in the browser URL and not by cookie. > > > > First of all I would personally slap anyone I work with for suggesting that we use DNS for load balancing. > > > > Secondly, the only mechanism you've mentioned that is replicating rather than centralising the session is DRBD. And finally, why do any of these mechanisms require passing the ID in the URL rather than a cookie? > There is no need for the mechanism right. So why do you suggest not using cookies? > > > > I'm curious to know what people are storing in their sessions. Is there anything larger than a few hundred bytes that is specific and unique to that session storage? What are the use cases for server-side session storage because it seems like I'm missing something? > > I store user rights in the session but also possible to do it with a DB query every time. Why not store those in an encrypted cookie? Unless we're talking about more than a couple of hundred bytes I see no reason to store them separately server-side or to hit the DB each time. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
