distributed php

[www.douglassdavis.com]

Just wondering, is there anything fundamentally that keeps php from
being "distribute d?"

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...

any one tried it?

[Gordon Burditt]

Re: distributed php

>Just wondering, is there anything fundamentally that keeps php from[color=blue]
>being "distribute d?"
>
>By that I just mean, run on many computers... Usually the only
>communicatio n between threads is through the database anyway right (not
>through shared objects)?[/color]

Session data is by default kept in a filesystem, not a database.
You can change that, though.
[color=blue]
>I'm thinking you could run it on multiple
>computers, using the same filesystem, and there shouldn't be
>problems...[/color]

A lot of large sites use dns round-robins (or level 4 switches) to
route HTTP requests to one of a whole bunch of nearly-identical web
servers, sometimes physically distributed around the country. They
either use a shared filesystem or copies of filesystems that are
supposed to be identical (tools like rsync may be useful here).
For that matter, the web site content might consist of a CD-ROM with
copies mailed to various sites with the servers.

One gotcha is the session data. A session on one system needs to
be accessible and valid on another system, since successive requests
might be to different servers. This is sometimes done with a session
handler that puts the session in a database used by all of the
servers. Another possibility is a shared filesystem for the session
files but generally a database works better and provides more locking
facilities. Stuff explicitly put in a database also needs to be
shared between the web servers.

You also need to write your PHP to use a database, not local files.

It does require a little thought, but it's not rocket science.

Gordon L. Burditt

[David Cartwright]

Re: distributed php

"www.douglassda vis.com" <doug@douglassd avis.com> wrote in message
news:1128730678 .638432.58380@g 44g2000cwa.goog legroups.com...[color=blue]
> 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...[/color]

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.

[Colin McKinnon]

Re: distributed php

David Cartwright wrote:
[color=blue]
> "www.douglassda vis.com" <doug@douglassd avis.com> wrote in message
> news:1128730678 .638432.58380@g 44g2000cwa.goog legroups.com...[color=green]
>> 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...[/color]
>[/color]

Yup, it scales really easily.
[color=blue]
>
> 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.[/color]

Actually, there are some options for storing shared information without
centralization. Cluster file systems are one way to go. Another which works
well for very large systems is to use sessionid addressing of the session
management systems (e.g. with N database servers, take the last few digits
of the sessionId - say 2345 - then the session information is stored on
server (2345 % N)). Since PHP allows you to write your own session handler
you can easily build your own solutions incorporating fault tolerance and
the storage substrate of your choice.
[color=blue]
> 3. Use a load balancer that is clever enough to load-share but send the
> same visitor back to the same server each time.
>[/color]

Doesn't work very well in practice. In addition to the loss of server
problem its not as easy as you might think to identify a client (ip address
can change mid session).

C.