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 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.
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...
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.
| Method |
KeepAlive |
suexec |
eaccelerator |
ioncube | response 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 |
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.
| Method |
KeepAlive |
suexec |
eaccelerator |
ioncube |
response ms |
Notes |
| 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 |
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.
| Method | KeepAlive |
suexec | eaccelerator |
ioncube | response 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 | 0 | 0 | 0 | 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.
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).
Updated March 22nd 2019: Adjusted tables for responsive design. Data not updated, although the tested PHP versions, extensions and methods are from today's point of view outdated.
AndyB from wrote on Nov 27th, 2012:
Thanks for publishing your test. But it seems that mod_suphp is not that much slower than mod_fcgid + eAccelerator(54ms compared to 45ms). I was under the impression that there's a huge gap.
Also I was under the impression that you need to disable suexec in order to install an opcode cache like eAccelerator on FastCGI.
Dominik from Poland wrote on Jun 26th, 2012:
I was not suprised by your results. If you need pure performance and run one app on the server, then mod_php is the fastest of all. But if you run several sites with different users then mod_fcgid\'s performance is equal as one can see on your charts (using suexec or suphp in such case is a must).
Really nice article
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb Icingaweb2 Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder