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.
To solve these problems, Apache and the mod_php module were developed, which allowed PHP code to be run directly inside the web server and to set up individual file access rights for each host. Although a separate process was still created for each request, some data was cached, which significantly accelerated execution compared to CGI. This gave a significant increase in speed.
Apache + mod_php became popular due to its ease of configuration. Apache is still one of the popular web servers for the web and is often used to create something quickly and without much configuration.
Popularity and market shares of web servers .
But using Apache to serve static content is not the best solution: even to receive an image, a “heavy” (with all modules like mod_php) handler will be used.
It is considered good practice to use Apache together with Nginx. Nginx effectively copes with the return of statics, and requests requiring the execution of PHP code are redirected to Apache. This significantly reduces memory consumption and increases the speed of request processing.
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, recent mobile phone number data 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).
Is there anything else that can be done to personalization that gets results peed up PHP scripts? More than one developer has asked themselves this question. In the search for a solution, technologies have been found that have radically changed the approach to processing requests:
- Support for long-lived processes. Unlike the traditional approach where the application is initialized each time a new request is received, you can load the entire application into memory once and use it to process incoming requests.
- Application-level HTTP server. Eliminates the extra layer between the server and the application, reducing overhead.
- Multithreading: Allows applications to handle more requests simultaneously within a single process.
- Minimizing the overhead of japan data interaction with FastCGI. By removing interaction with FastCGI and working with PHP code natively, we eliminate the overhead of processing each request.
Let’s look at the pros and cons of some ways to launch PHP applications:
1. Apache + mod_php
Created by: Apache Software Foundation. Written in C.
Pros:
- Easy to configure. mod_php is 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-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
Created by: Swoole Team. Written in C.
Pros:
- Support for long-lived processes.
- There is no need for a separate web server.
- Supports asynchronous I/O and coroutines, and can handle highly concurrent requests.
- Supports multiple network protocols, timers, process management, memory management and other features to meet various development needs.
- 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.
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.
