[NightlyDev]

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.

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.

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.

What you should choose depends on your need.

[maxymajzr]

> Mod_php was always faster at executing scripts

I've never, ever witnessed that mod_php came close to be fast, let alone faster than PHP-FPM. There's more work to be done in order to prepare everything needed for Apache to pass the data to PHP executable once it embeds it within its own process. Once opcache is up and running, PHP-FPM blows mod_php away (and there are tools to warm up the cache prior to letting the php-fpm node go live).

> 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

I've been present when the "hype" as you called it hit. It had nothing to do with memory as much as it did with scaling. Added benefit was the ability to have PHP-FPM act as a multiplexer towards certain services (database to name one).

Today, there's no reason to use Apache and mod_php. It's slower and worse by definition. It can't be faster. If you receive results that show it is faster, you're either testing it wrong or your PHP-FPM runs on a raspberry pi.

[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.