Posted by David Cartwright on 10/08/05 13:36

"www.douglassdavis.com" <doug@douglassdavis.com> wrote in message
news:1128730678.638432.58380@g44g2000cwa.googlegroups.com...
> By that I just mean, run on many computers... Usually the only
> communication between threads is through the database anyway right (not
> through shared objects)? I'm thinking you could run it on multiple
> computers, using the same filesystem, and there shouldn't be
> problems...

The main issue with load-sharing the front end of any Web site is preserving
session information - that is, ensuring that when a client turns up
brandishing a particular PHP-allocated session ID in its HTTP request
header, the server is familiar with that ID and can retrieve the appropriate
session information from its repository.

There are three ways to go:

1. Don't use session-based stuff - if you want to preserve state in your Web
site, pass variables around in GET requests.
2. Store the session-based stuff in a centralised database/filestore that
every server shares.
3. Use a load balancer that is clever enough to load-share but send the same
visitor back to the same server each time.

Option 1 is a pain in the butt to implement, and makes the URL messy, but
perhaps surprisingly many big sites use it because what you lose in ease of
implementation, you gain in reliability (if a server goes down, it doesn't
matter, and the load balancer's task is made simpler than with option 3).
Option 2 is probably the least attractive, because the central
database/filestore becomes both a single point of failure and a potential
bottleneck. Option 3 is pretty good too, though if a server goes down the
clients connected to it will lose their sessions and have to start again.

D.

[Back to original message]