If you are using WordPress, WooCommerce, Magento, Shopware, Oxid, a CMS or any other standard software, usually both the frontend and the backend use the same application fpm pool. Even for self-developed applications with Symfony or other frameworks this is often the case.
The backend / administrator can therefore include many slow operations, administrative operations and data exports that can take a long time. This could congest the web servers' processing queue reducing throughput for your customers who might just click the payment button and see a 502 Bad Gateway error.
Putting frontends and backends on different physical servers is a solution, but it can be too expensive for most use cases as we are effectively doubling the costs for the two machines or instances.
PHP-FPM Pool separation between frontend and backend
An effective solution to avoid bottlenecks in web applications is to configure Separate PHP-FPM pools for frontend and backend, each with distinct parameters for managing requests and resources.
To understand the concept, imagine running a bar with only one shared bathroom between customers and employees. At certain times, such as during a crowded party, you may find yourself with a long line: the customer has to wait for the employee to finish, and vice versa. This generates inefficiencies and poor service, slowing down staff work and worsening the customer experience.
It is for this reason that many places adopt a practical division: separate bathrooms for customers and staff, so as to avoid interference and conflicts of use.
Similarly, even in the server environment, it is useful Don't mix frontend and backend in the same PHP-FPM poolOperations performed by the backend—often slower and more intensive, such as report exports or administrative processing—can saturate resources and slow down responses to frontend requests, which are instead related to the user experience (page loading, checkout, login, etc.).
By separating the two environments into separate pools, it is ensured that slow backend operations do not block frontend user traffic, improving stability, responsiveness and overall quality of service.
Magento administration and frontend example
How does it look? Let's use Magento as an example, you can set up two pools in php-fpm.conf:
; php-fpm.conf [frontend] listen = /var/run/php-fpm-frontend.sock pm = static pm.max_children = 50 [backend] listen = /var/run/php-fpm-backend.sock pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 5
The frontend is configured for up to 50 concurrent requests and the backend for up to 5 concurrent requests. Back-end workers are created on demand and front-end workers are static to avoid fork overhead. I will discuss the differences between PHP-FPM pool configurations in a future blog post.
You can then change the Nginx vhost configuration for Magento installation with the following switch:
server { # More server directives... set $fpm_socket "unix:/var/run/php-fpm-frontend.sock"; if ($uri ~* "^/admin/") { set $fpm_socket "unix:/var/run/php-fpm-backend.sock"; } location ~ \.php$ { # Other FastCGI directives... include fastcgi_params; fastcgi_pass $fpm_socket; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } Based on the ^/adminpath in the request uri, it will now select the different PHP FPM pool and the frontend and backend will no longer compete and steal each other's resources.
If instead we were working with WordPress or WooCommerce the path would be ^ / wp-admin.
What matters is obviously the concept behind it, which is the ability to create separate and path-based queues.
