[mtbcoder]

> Mod_php was always faster at executing scripts. There is less overhead as you don't have to communicate like you have to with fpm.

The "overhead" of communicating via CGI to a PHP process has nothing to do with the speed of execution of the script itself.

> For light scripts this is far superior to fpm. On the other hand, always loading php does have it's downsides too as memory consumption can get quite high depending on the number of threads.

It's not far superior as the "overhead" of CGI is negligible in the real world. Plus you can pool processes for better scaling. Also, if you are using prefork with mod_php (which is the most probable scenario) it means you are forking an entirely new Apache process and not just "loading PHP" with each request.

> This is was also the reason for the fpm hype a long time ago: don't waste memory on php when php isn't needed. It had nothing to do with it running php faster.

It's not hype, because for a long time, mod_php required prefork because it was not thread-safe (even now it's still a pain to manage re-compiling PHP to be thread-safe for mod_php + Apache)...which means you could not take advantage of mpm_event or mpm_worker.

[g8oz]

Yes CGI just allows you to scale in a way mod_php doesn't. Apache & mod_fcgid are a great combo imo.

[stephenr]

Have you tried mod_proxy_fcgi? Being able to have similar handling for fpm and other proxied appservers (eg ruby or python stuff) is quite handy.