PHP is everywhere and is arguably the language most widely deployed on the Internet Web.
HOWEVER, it’s not exactly known for its high-performance capabilities, especially when it comes to highly concurrent systems. And that’s the reason that for such specialized use cases, languages such as Node (yes, I know, it’s not a language), Go and Elixir are taking over.
That said, there’s a LOT you can do to improve the PHP performance on your server. This article focuses on the php-fpm side of things, which is the natural way to configure on your server if you’re using Nginx.
In case you know what php-fpm is, feel free to jump to the section on optimization.
What is PHP-fpm?
Not many developers are interested in the DevOps side of things, and even among those who do, very few know what’s going on under the hood. Interestingly, when the browser sends a request to a server running PHP, it’s not PHP that forms the point the first contact; instead, it’s the HTTP server, the major ones of which are Apache and Nginx. These “web servers” then have to decide how to connect to PHP, and pass on the request type, data, and headers to it.
In modern PHP applications, the “find file” part above is the index.php, which the server is configured to delegate all requests to.
Now, how exactly the webserver connects to PHP has evolved, and this article would explode in length if we were to get into all the nitty-gritty. But roughly speaking, during the time that Apache dominated as the webserver of choice, PHP was a module included inside the server.
So, whenever a request was received, the server would start a new process, which will automatically include PHP, and get it executed. This method was called mod_php, short for “PHP as a module.” This approach had its limitations, which Nginx overcame with php-fpm.
In php-fpm the responsibility of managing PHP, processes lie with the PHP program within the server. In other words, the webserver (Nginx, in our case), doesn’t care about where PHP is and how it is loaded, as long as it knows how to send and receive data from it. If you want, you can think of PHP in this case as another server in itself, which manages some child PHP processes for incoming requests (so, we have the request reaching a server, which was received by a server and passed on to a server — pretty crazy! :-P).
If you’ve done any Nginx setups, or even just pried into them, you’ll come across something like this:
location ~ .php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
The line we’re interested in is this: fastcgi_pass unix:/run/php/php7.2-fpm.sock;, which tells Nginx to communicate with the PHP process through the socket named php7.2-fpm.sock. So, for every incoming request, Nginx writes data through this file, and on receiving the output, sends it back to the browser.
Once again, I must emphasize that this isn’t the most complete or most accurate picture of what goes on, but it’s entirely accurate for most DevOps tasks.
With that aside, let’s recap what we’ve learned so far:
- PHP doesn’t directly receive requests sent by browsers. Web servers like Nginx first intercept these.
- The web server knows how to connect to the PHP process, and passes on all the request data (literally pastes everything over) to PHP.
- When PHP is finished doing its part, it sends the response back to the web server, which sends it back to the client (or browser, in most cases).
Or graphically:
Great so far, but now comes the million-dollar question: what exactly is PHP-FPM?
The “FPM” part in PHP stands for “Fast Process Manager”, which is just a fancy way of saying that the PHP running on a server isn’t a single process, but rather some PHP processes that are spawned, controller, and killed off by this FPM process manager. It is this process manager that the web server passes the requests to.
