When it comes to running PHP applications, choosing the right web server is critical. To accurately assess the performance of popular servers, we tested them not on synthetic data, but on real data. We did not want to compile our own rating of web servers for running PHP applications. Our goal was to show the conditions under which a particular web server will demonstrate the best results.
PHP Runtime Applications: 30 Years of Evolution
In the beginning, there was CGI. It was one of the first technologies for running server scripts, which appeared in the 90s. CGI supports different languages, which makes this interface quite universal, but with its drawbacks. For example, for each request, the server creates a separate process for each CGI script, which leads to an overuse of system resources and greatly affects the performance and response speed of the server. Another known problem is running a script with the rights of a web server user. That is, if the server is configured incorrectly, the CGI script can access not only the files and resources of another application, but also the logs and configuration of the server, which creates a potential vulnerability.
Scheme of request processing by a web server.
Combining Nginx and Apache with mod_php provides a significant performance boost, but the mod_php module has a bottleneck: it runs the php interpreter in the context of each Apache process, which greatly increases resource usage.
For more efficient PHP execution, PHP-FPM (FastCGI Process Manager) was developed — this is an extended version of FastCGI, designed to increase productivity and reliability in high-load environments. Unlike mod_php, FPM launches a pool of worker processes that service requests independently of the web server itself. It should be borne in mind that detailed configuration is required to achieve maximum performance. It is also worth considering that some CMS (WordPress, 1C-Bitrix: Site Management) will require additional configuration since some of the rules are stored in .htaccess files (i.e. they are designed to be launched via Apache).
Let’s look at the pros and cons of some buy telemarketing data ways to launch PHP applications:
1. Apache + mod_php
Created by: Apache Software Foundation. Written in C.
Pros:
- Easy to configure. mod_php is enter this topic included in the standard Apache build.
- Stability. The solution is time-tested and has a large database of ready-made projects.
Cons:
- Resource-intensive. The module is loaded inside each Apache process, which greatly affects performance.
- Large increase in resource consumption under high loads.
- Lack of flexibility. Does not allow fine gambler data -tuning the configuration for each virtual host or sharing resources between processes.
2. PHP-FPM (PHP FastCGI Process Manager)
Created by: Andrey Pavlin. Written in C.
Pros:
- Became an official part of PHP starting with version 5.3.
- #2 on the list of popular ways to run PHP applications.
- It has good performance due to scaling of the worker pool.
- Possibility of flexible pool configuration.
- More debugging capabilities, including slow query log.
Cons:
- More complex setup compared to Apache(mod_php).
- It is necessary to configure interaction with the web server (Nginx).
- Resource intensity: Each request is processed by a separate PHP process, which increases RAM consumption under high load. There is also overhead due to communication via FastCGI.
3. PHP-PM (PHP Process Manager)
Created by: Mark Schlichtenmaier. Written in PHP.
Pros:
- Support for long-lived processes. As a result, the performance is better than php-fpm.
- Asynchronous processing. PHP-PM uses ReactPHP to provide asynchronicity, which significantly speeds up the processing of requests.
- Automatic reboot when code changes.
Cons:
- It is necessary to monitor memory.
- Requires a deeper understanding of how asynchronous PHP works.
- Small community.
- Less compatibility: Does not support all libraries and extensions that use synchronous mechanisms such as PDO or CURL, which operate in synchronous mode by default.
4. FrankenPHP
Created by Kevin Dunglas. Written in Go.
Pros:
- Support for long-lived processes.
- There is no need for a separate web server.
- Supports asynchronous request processing.
- Support for WebSockets and long-term connections.
- Supported in laravel octane (a library that allows you to install Swoole, RoadRunner or FrankenPHP with one command, without having to write worker code) ( https://github.com/laravel/octane ).
Cons:
- It is necessary to monitor memory.
- Requires restart when code changes.
- Requires a deeper understanding of how asynchronous PHP works.
- Small community.
- Without using laravel octane you need to write code for the worker.
- Complex setup. Requires more complex setup and implementation into existing projects compared to traditional solutions such as php-fpm.
5. RoadRunner
Created by: Spiral Scout. Written in Go.
Pros:
- Support for long-lived processes.
- There is no need for a separate web server.
- Asynchrony and multithreading: Supports asynchronous tasks.
- WebSocket and gRPC: Supports WebSocket, gRPC, and queues for building real asynchronous applications.
- Supported in laravel octane.
Cons:
- It is necessary to monitor memory.
- Requires restart when code changes.
- Requires a deeper understanding of how asynchronous PHP works.
- Small community.
- Without using laravel octane you need to write code for the worker.
- Complex setup.
6. Swoole
7. NGINX Unit
Creator: NGINX. Written in C.
Pros:
- Unit supports not only PHP, but also other languages such as Python, Go, Perl and Ruby.
- Supports dynamic configuration changes without restarting the server.
- You can run multiple applications simultaneously, which is convenient for microservices.
- Minimizes downtime and simplifies configuration management.
- There is no need to modify the application as in the case of long-lived processes.
Cons:
- Lower performance compared to long-lived process solutions.
- Small community: Unit is less popular compared to traditional solutions like PHP-FPM.
- Limited async capabilities: While Unit supports multiple languages and configurations, it still lacks async capabilities compared to solutions like Swoole or RoadRunner.
Comparison of application speed
There are many articles written and many tests conducted on the topic of comparing the speed of applications for running PHP. For example:
However, most of these tests are highly synthetic, i.e. the tested projects are not very similar to what you will eventually deal with (for example, the first article, where the server responds with json without database queries, or the second, where phpinfo is tested). To make the tests more realistic, we took an online store based on Laravel (Laravel Framework 10.41.0) — Bagisto (v2.2.2). We generated 5,000 products and configured it according to the deployment instructions (cache enabled and various debugging disabled).
