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? 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? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > BR/Torsten > > > "tedd" <tedd.sperl...@gmail.com> schrieb: > > > At 3:53 PM +0000 3/18/11, Stuart Dallas wrote: > > > Hi Tedd, > > > > > > Long time no chat, hope you're well. > > > > > > On Friday, 18 March 2011 at 15:44, tedd wrote: > > > > At 3:18 PM +0000 3/17/11, Stuart Dallas wrote: > > > > > > > > > > > Pragmatically speaking though, I'd say go for database backed > > > > > sessions until > > > > > > they actually become a performance bottleneck. > > > > > -snip- > > > > > > > > > > This may also be of interest: > > > > > http://stut.net/2008/07/26/sessionless-sessions-2/ > > > > > -Stuart > > > > > > > > > > -- > > > > > Stuart Dallas > > > > > > > > Stuart: > > > > > > > > I'm not getting the reason for storing a session in a db. > > > > > > If your site is being served by multiple servers you need > > > centralised storage of session data rather than the PHP default of > > > using files. Either that or the load balancer needs to use sticky > > > sessions which can lead to other issues depending on your traffic > > > patterns. > > > > > > My alternative to that is to bounce the minimum amount of data > > > necessary between the browser and server with each request. > > > > > > > In the scripts I have written that remember the user (i.e., "Hi > > > > Stuart"), I simply use a cookie stored on the user's computer. > > > > Sometimes it's just their name and other times it could be what/where > > > > they visited, or how they set their defaults, or any number of > > > > things. But everything that is needed and doesn't require > > > > authorization is set in a cookie that expires within a specific > > > > length of time -- usually a year. > > > > > > > > I don't see a need for storing session in the above case. > > > > > > That would be because there isn't one, but you'd be surprised how > > > often sessions are used for this type of thing. > > > > > > > If the scripts require an authorization, then I use sessions and a > > > > timer in concert. As long as the authorized user remains logged-in > > > > and the visit remains active, then the user enjoys the benefits of > > > > the visit. > > > > > > > > If the authorized user times out, then the session is destroyed and > > > > the user is asked to log-in again, generating another session. > > > > > > > > If the authorized user leaves the session (closes the browser) then > > > > everything is closed (session destroyed) and sometimes a cookie > > > > remains on the user's computer preparing for the next visit. > > > > > > > > The next time the user visits the site, everything (if anything) that > > > > is stored in user's cookie is addressed. But the user is asked to > > > > log-in again and another session is generated. > > > > > > > > In all cases where there is sensitive data, the user must log-in > > > > generating a new session. > > > > > > > > Again, I don't see how storing the current/past session provides > > > > any benefit. > > > > > > > > So, what am I not understanding or missing? > > > > > > > > Please show me how reactivating (if that is what this is) a session > > > > does anything. > > > > > > I don't recall anyone saying anything about reactivating old > > > sessions. The cookies I use to replace sessions are session-based > > > cookies and last no longer than a traditional PHP session. The key > > > is to provide a lightweight method of ensuring that whichever server > > > processes the request has access to the session data. > > > > > > -Stuart > > > > > > Thanks Stuart. > > > > You are always a couple of light years ahead of me. I'll have to > > study what you provided. > > > > Cheers, > > > > tedd > > > > -- > > ------- > > http://sperling.com/ > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
