A few system updates ago, PHP fell over completely because of some multi-processing module. The quick fix was to change the multi-processing module and avoid having to figure out what changed and how to use php-fpm. Part of moving my VM’s to the new server, though, is cleaning up anything I’ve patched together as a quick fix. And, supposedly, php-fpm is a lot faster than the old-school Apache handler. Switching was a lot less involved than I had expected.
dnf install php-fpm
My quick fix was to switch to a non-default multi-processing module. That change is reverted to re-enable the ‘event’ module
Configure Apache PHP Module
Verify the socket name used in /etc/php-fpm.d/ — Fedora is configured from /etc/php-fpm.d/www.conf with a socket at /var/run/php-fpm/www.sock
cp /etc/httpd/conf.modules.d/15-php.conf /etc/httpd/conf.modules.d/15-php.conf.orig vi /etc/httpd/conf.modules.d/15-php.conf # Handle files with .php extension using PHP interpreter # Proxy declaration <Proxy "unix:/var/run/php-fpm/www.sock|fcgi://php-fpm"> ProxySet disablereuse=off </Proxy> # Redirect to the proxy <FilesMatch \.php$> SetHandler proxy:fcgi://php-fpm </FilesMatch> # # Allow php to handle Multiviews # AddType text/html .php # # Add index.php to the list of files that will be served as directory # indexes. # DirectoryIndex index.php
Enable php-fpm to auto-start, start php-fpm, and restart Apache
systemctl enable php-fpm systemctl start php-fpm systemctl restart httpd
Voila — phpinfo() confirms that I am using FPM/FastCGI
We’ll see if this actually does anything to improve performance!