NYCPHP Meetup

[Dan Cech]

There are several different implementation floating around for 
database-backed session handling.

If you were to use one of those then all your session data could be 
stored on the database server (or a separate session server) and it 
would make no difference which webserver a request went to.

The only problems the majority of these systems have are the added 
overhead of retrieving the data from the session database vs the local 
filesystem, and the fact that implementing locks is fairly difficult.

Dan

Chris Hubbard wrote:

> I agree with you, that the load *probably* does not warrant load 
> balancing.  However, if it does, then would be nice/good/warm&fuzzy if 
> it worked as a load balanced app.
> 
> thanks for the bit about short commit times, completely forgot about that.
> chris
> 
> On Jan 7, 2004, at 4:45 PM, John Lacey wrote:
> 
>>
>>
>> Chris Hubbard wrote:
>>
>>> All,
>>> Here's a weird question for you all.
>>> Got a client who wants to run a couple different web servers, each 
>>> server running a copy of the same php application.  There will be 
>>> some sort (TBD) of load balancer between the servers and the 
>>> internet.  And there will be a separate server for the database.
>>> Users need to log into the application, and stay logged in while 
>>> using the application.  We want to be able to keep the users session 
>>> open even if one of the web servers crashes.  The users will be 
>>> conducting transactions (against PostgreSQL), so I can use the 
>>> transaction login in the database.
>>> My understanding is that if we're using $_sessions and the server 
>>> goes down, then, the user looses their session (and any work they'd 
>>> done).  One of the ideas we've come up with is using a cookie, so we 
>>> know from the inbound request who is making the request.  But I'm not 
>>> keen on cookies, for various reasons.
>>> We're anticipating no more than 50 concurrent users at any given 
>>> time.  I don't have an idea on how much load on a server a single 
>>> user will be.
>>
>>
>> Well Chris, on the face of it, that doesn't sound like an app that 
>> calls for load balancing at this point.  That, coupled with the 
>> [relatively] low odds of things crashing on users, it might be not be 
>> worth the effort.
>>
>> So far as "losing work" it would seem that an app would be written in 
>> such a way to have relatively short commit cycles.  i.e. don't leave a 
>> transaction uncommitted that depends on a user "thinking things over 
>> at the keyboard"
>>
>> Is there other compelling reasons why the client wants to run copies 
>> of the php app?
>>
>> John
>>
>>
>>
>>
>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nyphp.org
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
> Chris Hubbard
> chubbard at next-online.net
> 425 563 4153
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>