Many developers assume that the performance of a website depends on the server’s CPU performance and the connectivity of the server to its ISP.
Whilst this is true, another important factor on server performance is how the connectivity characteristic of the sites end-users impacts it

Keep in mind that a dynamic website consists of 2 components, creation of the dynamic page and then sending that data to the end-user.

Let’s look at a scenario from a plumbing perspective. Assume you have a water pump which takes finite time to pull water from a well and then send it to various end-users. There is only a fixed number of pipes available to deliver to end-users. The rate at which water can be pulled of is controlled by the rate at which the end-user can take the water (for now, assume that the size of the pipe to the end-user differs per end-user. If a situation arises that a lot of end-users with narrow pipes connect to the pump, the pump will have all its slots taken up by those narrow pipes and others (either with narrow pipes or fatter pipes) will have to wait. The pump becomes busy just serving water to the narrow pipes and isn’t doing what it does best, that is pull water from the ground.

Similarly, in a dynamic website one can only run a limited number of an application server because of memory and CPU constraints. If it gets busy serving customers who can’t pull data of it fast enough, this will delay others. So the solution is to have an intermediary talk to the end-user and the application server talks to the intermediary and then moves on to handle other requests. Such a situation is termed as having a ‘reverse-proxy’ sitting in front of your webserver.

At mumineen.org we are using Squid as our reverse proxy. Squid is primarily known as a forward proxy cache used by many ISP’s and we have tested our cache-friendly headers with it. It also has a mode wherby it can act as a reverse proxy or what Squid terms as “httpd accelerator” mode. Since Squid is an event driven single process program, it is very efficient CPU wise and by offloading our end-user connectivity to it, it frees up our Apache/PHP webserver to do what it does best, namely creation of the dynamic pages

Let’s see this with some numbers.

Let’s assume an average generated HTML page to be of 42KB and an average php script that generates this response in 0.5 second. How many responses this script could produce during the time it took for the output to be delivered to a user connecting at 56Kbps (7KB/s) ? A simple calculation reveals pretty scary numbers:

42KB / (0.5s * 7KB/s) = 12

12 other dynamic requests could be served at the same time, if we could put php to do only what it’s best at: generating responses.

This very simple example shows us that we need only one twelfth the number of children running, which means that we will need only one twelfth of the memory (not quite true because some parts of the code are shared).

With a reverse proxy, one can conceptually address security issues by filtering unwanted requests such as Nimda worms or connections to an admin URL from an unauthorised network segment. Reverse proxy’s are also used to provide SSL offload capabilities. Whilst Squid is not the only software based reverse proxy and we have plans to evaluate and possibly move to others, it was fairly easy to setup and with a brief tweak to our Apache config we can continue to capture client IP’s in our log.

In the commercial space, load balancer appliances such as Netscaler, F5 networks, Array Networks and many others have now incorporated reverse proxy functionality.

We hope that via the use of cache-friendly headers, compressed content and the use of a reverse proxy, we have setup an efficient infrastructure to help us serve the Dawoodi Bohra community.