Me Blog!

I’ve been on and on about using Squid as a reverse proxy that at times it must seem that I’m bordering on being completely obsessed with it. Well I suppose that is partly true. The performance boost that it can deliver is staggering and to get an idea of how well it performs look no further than Wikipedia who use it extensively. They claim that Squid serves up 78% of all their requests to their visitors which is a staggering amount in itself.

So why does it perform so well especially when compared to Apache running on its own?

The main reason is caching. When someone makes a request the proxy server checks to see if it has it locally and if it does it will serve that up directly instead of requesting it from a backend server. This of course depends on a number of factors. Primarily it will only cache static content such as images, css and javascript files as well as good old html. It will not cache dynamic content such as the contents of a blog post such as this one (although this can be done using memcached), however as it may well cache the ancilliary files associated with the page. The greater the number the times the same content is requests then the greater the chance that Squid will keep it in memoy increasing performance even more.

To use this post as an example, all the images, theme and javascript have more than likely been served to your browser by the proxy server, all that was requested from the web server itself was the text which has been pulled from a database using Apache and PHP.

So how much better does squid serve static content from its cache compared to Apache?

The quick answer is that it serves it staggeringly faster than Apache. For my test I used a single jpeg image that was 73KB in size. I then set up two virtual servers on my webserver and copied the image into both. I configured my internal DNS so that one of the sites would be served direct by the webserver and the other would be accessed via my reverse proxy.

Benchmarking was performed from a my main workstation using Apache Bench (ab). I used a concurrency of 10 and requested the image 100 times from each test site. So first up is the direct request:

Concurrency Level:      10
Time taken for tests:   2.621 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      7510044 bytes
HTML transferred:       7465900 bytes
Requests per second:    38.16 [#/sec] (mean)
Time per request:       262.082 [ms] (mean)
Time per request:       26.208 [ms] (mean, across all concurrent requests)
Transfer rate:          2798.37 [Kbytes/sec] received

That’s not too bad but here are the results when served by the reverse proxy:

Concurrency Level:      10
Time taken for tests:   0.640 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      7510100 bytes
HTML transferred:       7465900 bytes
Requests per second:    156.35 [#/sec] (mean)
Time per request:       63.960 [ms] (mean)
Time per request:       6.396 [ms] (mean, across all concurrent requests)
Transfer rate:          11466.60 [Kbytes/sec] received

It performed twice as fast when passed through the proxy server which is phenomenal!

However some of this performance could be attributed to differences in hardware. The webserver is a Sun 900Mhz UltraSPARC III and the reverse proxy a 3Ghz P4 but nonetheless it does demonstrate that the reverse proxy greatly accelerates performance when serving static content.