> --- In firebird-php@yahoogroups.com, "Nigel Weeks" <nweeks@...> wrote:
> > a better reason for using a database as the session storage
> mechanism is
> > that
> > it potentially allows sharing session data between multiple frontend
> > servers for
> > high capacity sites where incoming requests can be handled by one
> of any
> > number of
> > webservers (and there is no garantee that a client's requests will be
> > dealt with by
> > a single server.
>
> Yep, I can definately see an advantage in doing this that I wasn't
> seeing before. But at what typical load points do you think that
> branching into multiple servers becomes a need? I guess all
> applications will differ in size and complexity. But I'm curious
> where most developers consider the point where one should architect
> for this? Are we talking 100 concurrent users and greater, or
> something different?
>
> Myles
>

I agree with your other posting too Myles.
I would say that 100 concurent users is still well short of what would
require a load balancing approach.
You'd proabably need more like 100 simultaneous hits...
let's translate...
people have page latency - they don't just autoclick thru hundreds of
pages.. let's say min 10 seconds - max 2-3minutes, which averages to maybe
30 seconds for arguments sake.
to get 100 simultaneous hits/clicks out of 30 second latency would be 3000
concurrent users.
IIS and Apache have defaults of "unlimited" connections - in reality this
maybe 100,000 users.
So sessions for php and Apache/IIS are not the issue.
Alan