Matt Babineau wrote: >What if I made a network share and all the sessions were stored in a >shared space? > > In that case you are making the whole cluster in the health of the network file system (ie... the file system + the network sharing system)... but that wouldn't work, because if the user changes from the server a to the server b, it gets a new session initiated, because in that server, he hasn't a session... [or he has... depends on how php handles the session cookie and the session temp files]...
For instance... if PHP registers in the session temp file the name of the server and the ip, then the user, has it is accessing from a diferent server (with diferent ip and name), then even if the cookie is ok (ie is created using the root domain, and all the servers in the cluster are in the rule of *.domain.tld), it will not match with the file, with the consequence of generating a new session and the override of the session cookie. If the session temp file only registers the same root as the cookie, then, if all the servers follow the name rule of *.domain.tld, the session is persistent thru all the servers that use that share and comply with the naming rule... i've no idea of which is the case... testing will reveal... I would only deploy to production environment a session solution (either the share or any other) that supports clusters of servers after intensive testing... Cheers... Luis Ferro TelaDigital.Net >Matt Babineau >MCWD / CCFD >----------------------------------------- >e: [EMAIL PROTECTED] >p: 603.943.4237 >w: http://www.criticalcode.com >PO BOX 601 >Manchester, NH 03105 > > >-----Original Message----- >From: Luis Ferro [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, September 18, 2002 5:49 AM >To: [EMAIL PROTECTED] >Subject: Re: [PHP-WIN] SESSIONS- clustered environment > > >You have two solutions (IMHO): > >a) Database storage > > Replacement of the session_init and session_save/register functions >with others that will save/load the sessions from a database storage. > > Pros: easy to implement > Cons: dependency of the database storage reliability, scalability >problems > >b) Distributed sessions > > Replace the same functions with some that will propagate the session > >values to all the servers in the cluster, so that the next request can >be served by any and the session won't be corrupted. [this would mandate > >the existence of a "cluster" layer in the servers configuration] > > Pros: high availability, redundancy and scalability > Cons: very dificult to implement > >The first method can perform better in low trafic environments... but >will scale worst as the trafic will rise... the second method is much >more granular, with the performance cost more stable in all trafic >conditions, > >The first method will have is performance dependent on the performance >of the database storage... the second method will have performance >dependent on how many servers exist to syncronize the sessions... > >The non-cluster solution would be to have all the sessions register in >only one server, and get all the content in a second line of web >servers... that way, the main server would only handle connections and >sessions, with all the content and data communications bellonging to the > >second line servers... > >Cheers, >Luis Ferro >TelaDigital > >Matt Babineau wrote: > > > >>What would be the best way to handle sessions in a clustered >>environment without making the load-balancing persistant? >> >>Matt Babineau >>MCWD / CCFD >>----------------------------------------- >>e: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] >>p: 603.943.4237 >>w: <http://www.criticalcode.com/> http://www.criticalcode.com PO BOX >>601 Manchester, NH 03105 >> >> >> >> >> >> > > > >--- >[This E-mail scanned for viruses by Declude Virus] > > > > --- [This E-mail scanned for viruses by Declude Virus] -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
