Bug #48403 [Com]: shell_exec() is much slower than running from shell

Edit report at https://bugs.php.net/bug.php?id=48403&edit=1 ID: 48403 Comment by: oliver at openbrackets dot net Reported by: gregor at hostgis dot com Summary: shell_exec() is much slower than running from shell Status: Not a bug Type: Bug Package: Performance problem Operating System: Linux PHP Version: 5.2.9 Block user comment: N Private report: N New Comment: @ spam2 at rhsoft dot net Ok, calm down. The final comment was intended as a "joke", thought that might have been obvious? I know that php's most popular deployment SAPI is still apache, probably. Your usage is 100% opposite from ours. We have multiple own-iron app-servers running the same app for a single domain/app with load balancer in front. So we switched from apache 15yrs ago and never looked back. Hence the joke. The whole php process per webserver process/worker is completely unsuitable for our type of usage, so php-fpm was the obvious choice. Peace and love...enjoy. Previous Comments: ------------------------------------------------------------------------ [2018-01-20 13:08:59] spam2 at rhsoft dot net > Moral of story: Who runs php on apache anyway? Use nginx/lighttpd + php-fpm! laughable attitude! php-fpm brings a ton of other troubles (php-options per directory/htaccess and so on) and as long as a benchmark on a 6 years old 4-core desktop machine with current patchlevel (metldown/spectre) shows 10000 requests/second on our core-cms show me *one* valid reason for rebuild many hundret of vhost-configs with your perfered toy ------------------------------------------------------------------------ [2018-01-20 13:01:36] oliver at openbrackets dot net TL;DR this problem does not occur in php-fpm Just for the record, I did some testing with Imagick cmd line calls: (the Fill Area Flag "^" is not supported via Imagick extension) convert img.jpg -resize 200x200^ -gravity center -extent 200x200 thumb.jpg 100 operations on a 2MB jpeg image. Results below: bash loop: for i in {1..100}; do convert ... ; done : 4.4s php-cli : for ($i = 0; $i<100; $i++) { exec($cmd); } : 4.4s php-fpm : for ($i = 0; $i<100; $i++) { exec($cmd); } : 4.4s No difference whatsoever for this workload in the 3 environments. - No slow performance of "convert" - shell forking for each exec() call is insignificant for this test case php -v PHP 7.2.1 Moral of story: Who runs php on apache anyway? Use nginx/lighttpd + php-fpm! ------------------------------------------------------------------------ [2014-08-15 13:08:36] info at sistemasgsl dot com 15/08/2014 Same problem. It's a bug. ------------------------------------------------------------------------ [2009-06-01 23:23:00] gregor at hostgis dot com Our workaround is rather crude: I wrote a Perl CGI program, then have our PHP program run generate an URL to it and call file_get_contents() to collect the output. This is rather barbaric, but if PHP's exec() family runs at 1/6 speed, it seems our only option. This issue occurs only in PHP, and only when running as an Apache DSO. The issue does not occur with CGI programs in Perl or Bourne shell, so is not Apache's environment but something in how PHP and Apache work together. As such, the sentiment that "once we call exec() it's not our problem" seems less than productive. I am glad to continue working on it, as we would be most eager to see a real diagnosis and fix for this. ------------------------------------------------------------------------ [2009-05-28 04:34:04] gregor at hostgis dot com I get "current: -1 max: -1" in all cases. # su - www -c "/var/www/cgi-bin/foof" current: -1 max: -1 # curl http://localhost/cgi-bin/foof current: -1 max: -1 # php foof.php current: -1 max: -1 # curl http://localhost/~gregor/foof.php current: -1 max: -1 I agree, it's something about the shell environment which PHP sets up. The same command in a bash CGI doesn't do this, so it's not Apache forking, but PHP forking under Apache. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48403 -- Edit this bug report at https://bugs.php.net/bug.php?id=48403&edit=1