There are a lot of strange assumptions on that first page:
- "for example, if you are using PHP to access a database, unless that database has built-in access control" - well, of course I will use a database with access control like MySQL
- "It's entirely possible that a web spider could stumble across a database administrator's web page, and drop all of your databases". Of course I won't run PHPMySQLAdmin or Adminer on a production server, nor will I expose it to the public.
- also none of the above has anything to do with the PHP execution model
The second page might raise some valid issues but for instance the bullet point "mod_php is loaded into every httpd process all the time. Even when httpd is serving static/non php content, that memory is in use" - doesn't matter to me when I am running everything through index.php routing anyway.
"mod_php is not thread safe and forces you to stick with the prefork mpm (multi process, no threads), which is the slowest possible configuration" might be true but also a premature optimization.
Maybe mod_php is really bad but the arguments presented here are not very convincing to me.
It's simple and there is less overhead. Since PHP runs directly within the Apache process, there is no need for inter-process communication (no TCP, no sockets), reducing the overhead. This can lead to lower latency for individual requests.
mod_php does give you better response times for individual requests, but at the expense of being able to handle a higher load of traffic; you'll run out of memory and/or experience timeouts on mod_php way before you do with php-fpm.
With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
By having Apache proxy over to php-fpm for PHP requests, you can configure Apache to use mpm_event for serving static files, which allows for much leaner Apache workers (memory-wise) since they aren't carrying PHP around on their backs.
While you're at it, you can use haproxy on the same machine for TLS termination, then you can disable mod_ssl thus making Apache workers even lighter.
> With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
Yes, that is true. But most high-traffic websites will cache static files such as CSS files and images, using a reverse proxy (e.g. Varnish, a CDN, or usually both). So I don't think this is a real problem, most of the time (99.9%?), a request for a static file will not hit Apache.
I'm not saying mod_php is better for all scenarios, of course, but I think it can be ok.
I tend to agree with you - using in "default" setup with mod_php and mpm_prefork is known to be far from optimal (still fine for blog about you and your cat).
With reverse proxy in front of such setup is - much better in terms of performance. For shared hosting - yet again, may be not optimal if one needs to support multiple system users.
It's a security nightmare. https://www.php.net/manual/en/security.apache.php
Even Apache httpd discourages the usage of mod_php. If installed, Apache recommends some extra configuration to limit memory leaks. https://cwiki.apache.org/confluence/display/HTTPD/php