Almost every system admin is aware of the different possibilities how to install PHP. Besides already pre-packaged versions on Linux distros there are even more ways to install PHP from source packages.
The biggest discussion on the Internet is if PHP should be installed as a direct Apache Module (mod_php) or if it should be launched as a CGI process (php-cgi binary called by an Apache Module). Depending on the importance of the web server or on the personal opinion of another system admin in his blog or in a forum post, the 'perfect' solution varies.
I've read hundreds of posts that mod_php should not be used for security reasons but then using PHP with the php-cgi as FastCGI process was called to be slow. Unfortunately I haven't found real proof (in numbers) of all the descriptions, so I decided to run some tests on a new physical machine, without any active websites. This testing took me some weeks, mainly the preparation of the different possibilities of implementing PHP as some of them are rather complex.
The testing setup
The performance of the target web server is checked by using the utility 'httperf', which simulates parallel access of the target website.
The target server runs Apache2-mpm-worker.
The target website is a single PHP page with MySQL connections.
The target website is accessed with a rate of 50 requests/second which should simulate a real web hosting environment (50 concurrent users).
The target server runs PHP 5.3.8, compiled exactly the same way for all tests.
The performance tests are done on a virtual server running Debian Lenny. The target web server is running Debian Squeeze.
Both servers (target and test server) have a fixed IP address and a steady Internet connection to more or less the same bandwidth at all times.
Procedure
The target website is checked with the following command:
httperf --server=www.[TARGETWEBSITE].ch --uri=[/TARGETPAGE] --rate=50 --num-conns=1000
After each test, Apache is restarted and memory is synced:
/etc/init.d/apache2 restart
sync
After three tests, the best test result is taken.
The Reply time in ms will be used as test result.
After the three tests, the configuration of Apache/PHP is changed and another three tests follow... etc...
Testing: Apache2 + mod_php
mod_php is supposed to be the easiest installation of PHP. The module is directly loaded from Apache and runs therefore within the Apache process. It is supposed to be fast but not secure because every PHP script is executed with the permissions of the user of Apache (wwwrun or www-data on most systems). After the tests, it clearly shows that the setup with KeepAlive and eaccelerator as caching extension is the fastest.
|
KeepAlive |
suexec |
eaccelerator |
ioncube |
Reply ms |
|
Notes |
| mod_php |
1 |
0 |
0 |
0 |
41.1 |
|
suexec no effect with mod_php |
| mod_php |
0 |
0 |
0 |
0 |
48.1 |
|
suexec no effect with mod_php |
| mod_php |
0 |
0 |
1 |
0 |
38.7 |
|
suexec no effect with mod_php |
| mod_php |
1 |
0 |
1 |
0 |
36.4 |
|
suexec no effect with mod_php |
| mod_php |
1 |
0 |
1 |
1 |
35.9 |
|
suexec no effect with mod_php |
| mod_php |
0 |
0 |
1 |
1 |
36.5 |
|
suexec no effect with mod_php |
Testing: Apache2 + mod_suphp
mod_suphp is almost as easy to install as mod_php because it is directly launched as an Apache module. With suphp it is possible to launch the PHP scripts with the rights of the owner of the PHP file to launch. However, PHP extensions like eaccelerator or Xcache are not possible to use.
| mod_suphp |
0 |
0 |
0 |
0 |
45.3 |
|
no php extensions with suphp |
| mod_suphp |
1 |
0 |
0 |
0 |
57.3 |
|
no php extensions with suphp |
Testing: Apache2 + FastCGI
Launching PHP as a FastCGI process is the most complex to do but supposed to be the most secure. To add complexity to the matter, there are two (probably even more) FastCGI Apache modules available: mod_fcgid and mod_fastcgi. The setup for both can be the same but both modules handle requests a bit differently. By using suexec the PHP scripts are launched as the user and group given by the Suexec definition.
|
KeepAlive |
suexec |
eaccelerator |
ioncube |
Reply ms |
| mod_fcgid |
1 |
0 |
0 |
0 |
91.9 |
| mod_fcgid |
1 |
1 |
0 |
0 |
96.3 |
| mod_fcgid |
0 |
1 |
0 |
0 |
119 |
| mod_fcgid |
0 |
0 |
0 |
0 |
98.4 |
| mod_fcgid |
0 |
0 |
1 |
0 |
58.7 |
| mod_fcgid |
0 |
1 |
1 |
0 |
60.2 |
| mod_fcgid |
0 |
1 |
1 |
1 |
60.5 |
| mod_fcgid |
1 |
1 |
1 |
1 |
54.3 |
| mod_fcgid |
1 |
0 |
1 |
1 |
56.4 |
| mod_fcgid |
1 |
0 |
0 |
1 |
89 |
| mod_fcgid |
0 |
0 |
0 |
1 |
90.4 |
| mod_fcgid |
0 |
1 |
0 |
1 |
92.5 |
| mod_fastcgi |
0 |
0 |
0 |
0 |
54.3 |
| mod_fastcgi |
0 |
1 |
0 |
0 |
66.8 |
| mod_fastcgi |
0 |
1 |
1 |
0 |
55.3 |
| mod_fastcgi |
0 |
0 |
1 |
0 |
59.6 |
| mod_fastcgi |
1 |
0 |
1 |
0 |
60.4 |
| mod_fastcgi |
1 |
1 |
1 |
0 |
78.1 |
| mod_fastcgi |
1 |
1 |
1 |
1 |
74.6 |
| mod_fastcgi |
0 |
1 |
1 |
1 |
80.9 |
| mod_fastcgi |
0 |
1 |
0 |
1 |
92.1 |
| mod_fastcgi |
1 |
1 |
0 |
1 |
81.5 |
| mod_fastcgi |
1 |
0 |
0 |
1 |
85.4 |
| mod_fastcgi |
0 |
0 |
0 |
1 |
65.4 |
To my big surprise, mod_fcgid seems to be by far slower than mod_fastcgi when PHP is used without the caching extension eaccelerator (98.4ms fcgid, 54.3ms fastcgi) but as soon as eaccelerator is used, fcgid takes the lead (58.7ms fcgid, 59.6ms fastcgi). It is even more clear as soon as all modules and extensions are loaded: It took fcgid 54.3ms to deliver the web-page compared to 74.6ms with fastcgi.
Conclusion
At least there is now something black on white which proofs that mod_php is by far the fastest setup of PHP (35.9ms). By using mod_fcgid the security can be greatly enhanced and by enabling a caching solution (here eaccelerator) it is not even sooo much slower (54.3ms).
|
![[Valid RSS]](https://validator.w3.org/feed/images/valid-rss-rogers.png "Validate my RSS feed"){kind=small}
