C++ and PHP benchmarking
Benchmarking tests run on simple C++ and PHP web applications running on Nginx/FastCGI and Apache/mod_php respectively show that, for comparable tasks, Nginx/FastCGI/C++ performed between 35% and 50% better than Apache/mod_php in this case.
The architecture of both applications was comparable, both using a file include strategy. In both cases, all requests were rewritten to a single index file which then selected the appropriate content to include using the original request as a parameter. The index file (a kind of simple page controller) simply wrapped the content of the included file with a common header and footer. The C++ application used standard fstream functions to read files, while the PHP application used the require() function.
Both web servers were run on the same operating system (CentOS 5 x86_64 virtual machine with 512MB RAM and one virtual CPU), with only a single server running at any one time. The Nginx server (v 0.7.64) was a rebuild of a Fedora SRPM, with a FastCGI 2.4.0 backend. The Apache server (v 2.2.3) was the CentOS 5 default, with PHP 5.2.6 (mod_php) from CentOS Testing. The VM was running on a CentOS 5 Xen host running on a Xeon quad core box with 4GB RAM in total.
The benchmarking sofware was ab (Apache Bench). On each run, 1000 requests were run against the server. Two levels of concurrency were tried (1 and 10). Two versions of each script were used, script 1 containing the text of the GPL v3 and script 2 containing that text in addition to several arithmetic calculations.
Files
The HTML pages returned by both applications were identical in size and content apart from the title. The pages being returned were (note that the links in these HTML documents don't work here):
The application scripts (this is testing code only, definitely not production ready):
- C++ Script 1: C++ program using the FastCGI++ library.
- C++ Script 2: As above, but with some arithmetic work added.
- PHP Script 1: PHP script.
- PHP Script 2: As above, but with some arithmetic work added.
The raw AB results are available here. The results in the table below are averages across three runs for each test.
| Metric | Concurrency 1 | Concurrency 10 |
|---|---|---|
| Nginx + FastCGI + C++ : Script 1 | ||
| Requests per second | 133.27 | 132.47 |
| Time per request (ms) | 7.52 | 7.56 |
| Transfer rate (Kb/s) | 4644.67 | 4617.02 |
| Apache + mod_php : Script 1 | ||
| Requests per second | 87.47 | 86.25 |
| Time per request (ms) | 11.46 | 11.59 |
| Transfer rate (Kb/s) | 3051.39 | 3008.81 |
| Nginx + C++ : Script 2 | ||
| Requests per second (mean) | 129.13 | 137.37 |
| Time per request (ms) | 7.79 | 7.28 |
| Transfer rate (Kb/s) | 4535.98 | 4825.34 |
| Apache + mod_php : Script 2 | ||
| Requests per second (mean) | 95 | 95 |
| Time per request (ms) | 10.53 | 10.49 |
| Transfer rate (Kb/s) | 3340.28 | 3352.15 |
Observations
- C++ on Nginx/FastCGI delivered approximately 50% more requests per second than Apache/PHP for Script 1.
- Apache/PHP took approximately 50% longer per request than C++ on Nginx/FastCGI for Script 1.
- The transfer rate in Kb/s was approximately 50% greater from the Nginx/FastCGI server for Script1.
- For the same measures, Nginx/FastCGI ranged from 35% (@ concurrency 1) to 45% (@ concurrency 10) better performance than Apache/PHP for Script 2.
- Nginx/FastCGI/C++ appears to have performed better with a concurrency of 10 for Script 2 than a concurrency of only one(?)
Comments
This exercise involved one test of one application in one context, and there are many variables involved. Nevertheless, it is clear that C++ web applications have the potential to perform in the region of 50% better than comparable PHP applications. It could be argued that with various optimisations of both Apache and PHP, these figures would be very different, and that is true. But most shared hosting ISPs don't optimise their servers in this way, and can't given the diversity of needs of their client base. What I am interested in are the millions of bog-standard web applications out there running on bog-standard web servers, not highly tuned custom setups. As I see it, building more efficient mass-hosting web applications running on more efficient web servers could save at least 30% of the resources (hardware, electricity, etc) currently used to run a large sector of the internet. The resources consumed by any single inefficient web application are minute, but when scaled to millions of inefficient web applications the environmental impact becomes significant.