melbourne chapter

PHP Web applications scale very well. When PHP executes it loads your previous sessional variables (if used and if there is any), performs a task, writes your session to disk (if sessions are used) and exits. This is different to a Java Web container which has a process handling requests at all time, with your application running from start to finish.

Due to this “start-process-finish” requests can be processed without worrying greatly about affecting data in other processes. It also means that if our storage is shared (for sessions etc) and we use some intelligent network level routing we can have requests processed by several different servers. When more requests are needed we can simply pipe on more servers, without worrying too much about managing the state across the servers.
When we are using virtual servers for our hosting we must consider about how load is handled. Generally cheaper hosting usually means that it is either hosted in america, using a poor tier of hosting (cheap bulk) or jamming a large amount of domains onto single servers (having a high ratio of servers to domains). All usually results in slower performance of your website.

I have been using a group out of Western Australia for my shared hosting. After doing research into them and their setup it seems very full proof. Damian Douglas-Meyer (a technician there) explains:

Our load balancing system works like this:

1. Today, there are 10 identical Linux servers, each running Apache and ProFTPD for HTTP and FTP respectively. 2 of these are dedicated for FTP although all can do FTP or HTTP.
2. All servers are configured for and can respond for all sites and share a common file system via a NetApp filer.
3. There is a central load balancing switch that listens for the common IP address 203.202.10.111 and initially receives the packets.
4. The load balancer monitors server health and also load, based loosely on the number of current connections to each server. It also remembers client IP addresses that have connected to each server within the immediate past.
5. When the load balancer receives a packet, if possible it passes the request onto the same webserver that processed the requests from that client. This is to keep PHP and other sessions alive. Otherwise it passes the request to the least loaded webserver, modulo some other settings for distributing load.
6. The webserver gets the request as if it came directly from the client due to some network level packet re-writing. It process the request in the same way it would as if it was the only webserver for that site, and returns the data to the client.

So in essence, if 100 people were accessing your site at any one time, 10 of them would be processed by each server. An individual client would stay with the same server for the life of a session.

If one server gets busy due to other clients consuming resources, the load balancer knows this based on response times of its’ heartbeats and reduces the level of new connections to that server.

If a server dies, connections are passed to other servers, although in this situation, PHP sessions can be lost (unless stored in your own tmp directory under your home directory, or in a central database.)

Regarding peaks and troughs in load, there are times when some servers get busy due to specific clients running demanding scripts. We do place limits on memory, CPU and execution time of scripts to mitigate issues with these situations. If we notice some clients abusing the servers with poorly written perl cgi’s, for example, we will work with the customer to improve their script, or quarantine them on a separate server for the good of all customers

This sort of scenario is very appealing to us, due to the way that our PHP applications can be handled by several servers without worrying about scalability issues of a single web container instance. This scenario is good to have if you are internally hosting your applications. If your server become under high load you can simply setup another server in the cluster [although a theoritical bottleneck would come of the storage medium first].
RE the company I use for hosting: Another attractive feature is that they are using a high-grade australian bandwidth, generally meaning that your website will load quickly for australian viewers, and because they are close to the top tier, international traffic is quite good as well. They provide excellent prices (starting from around $180 per year - 500mb, 10GB traffic, unlimited email, and Urchin Webstats [can be automatically emailed to your client every day/week/month]). The accounts are customisable and have the ability to scale only traffic without having to pay for more space - (so you don’t have to fork out money for several gig of space if all you want is lots of traffic). You can get a 5% discount on the price using my referral. Their support is outstanding and I have found it to be a very proffesional way to host our domains. I first came across them because PHP.net uses them as a mirror because of their capability to handle demand. Must be good