Bug #48403 [Com]: shell_exec() is much slower than running from shell
| From: | spam2 at rhsoft dot net | Date: | Sat, 20 Jan 2018 13:09:01 +0000 |
| Subject: | Bug #48403 [Com]: shell_exec() is much slower than running from shell | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-213634@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=48403&edit=1
ID: 48403
Comment by: spam2 at rhsoft 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:
> 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
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2009-05-27 23:03:07] rasmus@php.net
That points to memory thrashing to me. The brk calls are fiddling with the data segment size.
Compile this little test:
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
int main() {
struct rlimit rlim;
getrlimit(RLIMIT_DATA,&rlim);
printf("current: %ld max: %ld\n",rlim.rlim_cur,rlim.rlim_max);
}
And shell-exec that from php-cli and from php-apache and see what you get. Just want to double
check that you are indeed running in the same environment in both. You could also check removing
all ulimits from the php-apache environment and see if that makes a difference.
It still isn't something we can fix here. By the time you have done the fork+exec, PHP is out
of the picture. It is down to the OS and the environment the shell exec is running in at that
point, so you need to figure out how that environment differs between the two.
------------------------------------------------------------------------
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