distributed php

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

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

any one tried it?

Re: distributed php

Quoted text here. Click to load it

Session data is by default kept in a filesystem, not a database.
You can change that, though.

Quoted text here. Click to load it

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

Re: distributed php

Quoted text here. Click to load it

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.


Re: distributed php

David Cartwright wrote:

Quoted text here. Click to load it

Yup, it scales really easily.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Site Timeline