ID: 48403 User updated by: gregor at hostgis dot com Reported By: gregor at hostgis dot com Status: Bogus Bug Type: Performance problem Operating System: Linux PHP Version: 5.2.9 New Comment:
> 1. Higher memory footprint for Apache+PHP which means > less memory left for the shell exec I'd think that 1024MB would be enough for a 60MB process! But, see below for some very interesting strace results. > 2. Different non-privileged user id, most likely which > could affect where temp files are stored and such Doesn't affect the tempfile storage, and the system only has the one disk array and no ramdisks) so all places would be equally fast. I'm also the sysadmin, I know their hardware pretty well. > 3. If you are running your Apache in a vm or a chroot > environment, things might be very different there Nope. Again, I'm the sysadmin and I did not configure it as such. > 4. You will probably have less file descriptors available > to you, so if your shell exec needs a lot, it may be starved User 'www' gets the same 1024 FDs as everybody else. I verified that way back, by su'ing to www and running the same command and PHP apps from Bash, PHP CLI, and Apache. The output of 'ulimit -a' is identical for user www and for my regular account. > Comparing the strace output from > the two along with some intermediate timings > as you mentioned would be interesting. Coming right up, and boy is it interesting. Previous Comments: ------------------------------------------------------------------------ [2009-05-27 22:07:29] [email protected] Interesting. So, the differences between the fork+exec from PHP-CLI and PHP-Apache might be: 1. Higher memory footprint for Apache+PHP which means less memory left for the shell exec 2. Different non-privileged user id, most likely which could affect where temp files are stored and such 3. If you are running your Apache in a vm or a chroot environment, things might be very different there 4. You will probably have less file descriptors available to you, so if your shell exec needs a lot, it may be starved of those That's all I can think of right now. Comparing the strace output from the two along with some intermediate timings as you mentioned would be interesting. ------------------------------------------------------------------------ [2009-05-27 22:01:59] gregor at hostgis dot com > [email protected] > Any exec() function implies fork() > This may explain the time it takes I'm not sure I follow you. When I watch the 'top' and 'ps axu' output, the shp2img or gdal_translate task is running the whole time. It is not spending 68 seconds forking and then running the job in 14 seconds. This same program from CLI, does not exhibit this slow execution. If fork() is being slow, surely it would affect the CLI version? And if I run the shp2img command from a four-line Bourne shell CGI script, it runs in 14 seconds -- that seems to eliminate Apache and fork() as likely culprits. What I find bizarre, is that the shp2img process has exactly the same 'top' and 'ps axu' output in both cases: 59 MB RSS, 115 MB VSZ, 9.8 MB shared memory, 99-100% CPU. Overall system CPU usage hovers at 40%, with only flickers of "wait" -- this too is identical regardless of how shp2img is started. > [email protected] > It could also be a memory issue. > If you are running up against the per-process memory-limit > then the code may run much slower as it has to > try to do the same image operations in less memory. I have memory_limit set to 256 MB Since shp2img for this case uses 60 MB, this should be plenty. Still, I have upped it to 1024 MB (we have a lot of RAM to play with) and this had no effect. I will run some profiling/timing stuff from within shp2img, since its debug output includes tmestamps, and get back to you with those. ------------------------------------------------------------------------ [2009-05-27 21:22:11] [email protected] It could also be a memory issue. The fork overhead would be a constant on all shell execs. However, manipulating a large image is a memory-intensive operation. If you are running up against the per-process memory-limit then the code may run much slower as it has to try to do the same image operations in less memory. But again, I don't see how this could be called a PHP issue. Check your per-process limits and see if increasing them makes a difference. ------------------------------------------------------------------------ [2009-05-27 21:18:48] [email protected] Any exec() function implies fork(). This means the apache process (and potentially all its threads) have to be forked before the exec(). This may explain the time it takes (and this is why apache2 as a separate daemon to spawn CGI processes). ------------------------------------------------------------------------ [2009-05-27 21:07:57] gregor at hostgis dot com > This proves it's not bug: > run from shell - 14 seconds > PHP on CLI - 14 seconds I disagree. It means that the bug is evident only when running under the webserver, which introduces a few more variables. > And since you're using 3rd party extensions (Zend Optimizer) > -> bogus. Please contact Zend for support. I have disabled Zend Optimizer. It had no effect on the times at all: 13-15 for CLI, 80-85 for the same command being run in a ten-line PHP program. ------------------------------------------------------------------------ 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 http://bugs.php.net/48403 -- Edit this bug report at http://bugs.php.net/?id=48403&edit=1
