PHP Hello World Benchmark 2014
LiteSpeed vs. NGINX
This benchmark compares the speed at which different web servers respond to requests for small PHP scripts using both non-keep-alive and keep-alive connections.
With no keep-alive connections, LiteSpeed Enterprise (with either suEXEC Daemon mode or ProcessGroup) was
- 3361% faster than Apache 2.2 using suPHP.
- 3911% faster than Apache 2.4 using suPHP.
- 55% faster than Apache 2.2 with mod_PHP.
- 220% faster than Apache 2.2 with PHP-FPM.
- 174% faster than Apache 2.4 with PHP-FPM.
- 26% faster than nginx with PHP-FPM.
- 23% faster than LiteSpeed Enterprise with PHP-FPM.
- slightly faster than OpenLiteSpeed
With keep-alive connections, LiteSpeed Enterprise (with either suEXEC Daemon mode or ProcessGroup) was
- 3885% faster than Apache 2.2 using suPHP.
- 4506% faster than Apache 2.4 using suPHP.
- 50% faster than Apache 2.2 with mod_PHP.
- 273% faster than Apache 2.2 with PHP-FPM.
- 203% faster than Apache 2.4 with PHP-FPM.
- 91% faster than nginx with PHP-FPM.
- 16% faster than LiteSpeed Enterprise with PHP-FPM.
- slightly faster than OpenLiteSpeed.
In both tests, LiteSpeed Enterprise returned essentially the same results with suEXEC daemon mode and ProcessGroup.
It should also be noted that, even using the same PHP-FPM backend, LiteSpeed Enterprise outperformed all participants not using LSAPI. This is due to its optimized coding.
- We used a simple PHP hello world script (13 bytes). We used such a tiny script to avoid saturating the network connection and to show raw speed differences between the different setups.
- Part of the difference in speeds is due to different server APIs. OpenLiteSpeed and LiteSpeed Enterprise with ProcessGroup and suEXEC daemon mode all used LSAPI. PHP-FPM uses FCGI. suPHP uses CGI. mod_PHP is embedded in the web server.
- Opcode caching was not used for any of these setups. With opcode caching, differences would have been more marked. Fast setups would have shown an even larger advantage over slower setups.
- LiteSpeed's suEXEC daemon and ProcessGroup modes returned the same results in these tests. In the real world, though, they have different advantages and uses. Each has situations where it would be preferable over the other. For more information on this, see our PHP LSAPI documentation.
- The benchmark simulated serving 50000 requests to 100 users.
- Access logging was disabled for all web servers to minimize disk I/O.
- The test was performed over a 10GBps network connection to make sure network bandwidth did not become a bottleneck.
- As the server CPU was faster than the client machine CPU, the test client "ab" could have become a bottleneck before the server reached its peak performance. We thus created an OpenVZ container on the server and assigned it 50% of one CPU, allowing the server to reach 100% CPU utilization during all tests.
- For the keep-alive test, all web servers are configured to a maximum 100 keep-alive requests.
Server hardware specs:
Supermicro X9SRH-7TF Intel Xeon E5-1620 Quad Core @ 3.60GHz 8GB RAM CentOS 6.4 with OpenVZ kernel 2.6.32-042stab081.8 Intel X540 10GBASE-T on board NIC Host IP: 192.168.0.22 Hard Drive: Samsung HD103SJ 1TB 7200rpm
Client hardware specs:
Supermicro SYS-6016T-6RFT+ Dual Intel Xeon E5620 Quad Core @ 2.40GHz 32GB RAM CentOS 6.4 with OpenVZ kernel 2.6.32-042stab081.8 On board Intel 82599EB 10 Gigabit Ethernet Controller Host IP: 192.168.0.20 Hard Drive: On board LSI 2108 RAID controller Samsung HD103SJ 1TB 7200rpm X4 in RAID5
Netgear XS708E-100NES 8-ports 10G switch
We welcome your feedback on our forum.