On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote:
> "Stuart Dallas" <stu...@3ft9.com> 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

Reply via email to