6 ms·
The issue is PHP-FPM (FastCGI) only and it's vulnerable from outside only with nginx. The vast majority of PHP 7.0 installations don't use FastGCI and don't us
by kgersen75 7y ago
The issue is PHP-FPM (FastCGI) only and it's vulnerable from outside only with nginx.
The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx but Apache simply because people used 'apt install php' (or 'yum install php') to install it.
So imho, the impact is very limited.
- cbg0 7y ago> The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx Do you have a source for this?
- wolco 7y agoCommon approach is to serve static files with nginx and use apache / php_mod to process. Why are you running php-fpm? Do you need to separate request's processes? The speed benefits of php-fpm are part of php 7 so using php_mod is faster now.
- oefrha 7y ago> Why are you running php-fpm? Because running just nginx is more convenient than nginx + Apache, where Apache is only used for mod_php. For me anyway. (I only use nginx + php-fpm for a Wordpress instance; I have tons of stuff in other languages running on top of nginx too.)
- cbg0 7y ago> Common approach is to serve static files with nginx and use apache / php_mod to process. Not sure how common that really is, I've personally never set things up like that and just use nginx + php-fpm and don't know anyone that still uses apache with mod_php.
- wolco 7y agoWe went from php_mod to php-fpm but we started moving back to php_mod after php 7 came out showing the benchmarks.
- larzang 7y agoThat's true for us as well with our legacy applications. Our newer applications are using litespeed instead, and we've found it to be significantly better. You basically get the features of a nginx + apache + varnish stack in a single easily managed service and with better performance too.
- locusm 7y agoI think its the default on Plesk installs
- snuxoll 7y agoPlenty of stuff still uses it, unfortunately. Performance is pretty janky, I just moved a Mediawiki install from Apache+mod_php to Nginx+php-fpm as part of getting the site(s) on kubernetes and it’s tremendously better to work with and uses less memory due to not needing mpm_prefork.
- shakna 7y agoPHP-FPM + Nginx is the standard approach for OwnCloud & NextCloud. I'm sure they're not the only stacks that use that approach.
- stephenr 7y agoWhy are you not running php-fpm with Apache is a more pressing question IMO.
- wolco 7y agoSpeed mostly.
- stephenr 7y agoI was under the impression that a properly tuned mpm_event and fpm has very little difference to mpm_prefork and mod_php. What sort of machines are you running this on and what sort of child proc numbers are you running?
- maxymajzr 7y agoCan you elaborate? I've yet to see Apache + mod_php to be capable of coming even close to <anything> + PHP-FPM so I'm really interested in what you guys are doing.
- NightlyDev 7y agoMod_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.
- mtbcoder 7y ago> 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.