ID: 48403 Updated by: [email protected] Reported By: gregor at hostgis dot com Status: Bogus Bug Type: Performance problem Operating System: Linux PHP Version: 5.2.9 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2009-05-27 20:02:43] [email protected] This proves it's not bug: run from shell - 14 seconds PHP on CLI - 14 seconds And since you're using 3rd party extensions (Zend Optimizer) -> bogus. Please contact Zend for support. ------------------------------------------------------------------------ [2009-05-27 19:43:53] gregor at hostgis dot com > Perhaps you can provide me the same image to test with The file is available for a short time at this URL: http://www.cartograph.com/images.tmp/2043.tif.gz It's a 3 GB TIFF, but gzipped for faster download. > Apart from different file, I did exactly same as you. I find the result of 0.04 seconds fishy, though. I assume that you have GDAL installed when you run the test? > You didn't specify whether you run that test under > some webserver or using PHP CLI? Here's where we get into how I narrowed it down to being something about PHP and Apache. run from shell - 14 seconds PHP on CLI - 14 seconds PHP as Apache DSO - 84 seconds Perl CGI - 14 seconds I would have to set up a dedicated test server in order to test other scenarios, such as disabling Zend Optimizer or running PHP as CGI. On our production server, those are not an option. Note that the 14/84 test is for a shp2img using this same TIFF and a mapfile -- the gdal_translate was <1 second to 4 seconds. I will be glad to provide those as needed, if the gdal_translate test fails to replicate our results on your environment. ------------------------------------------------------------------------ [2009-05-27 18:49:35] [email protected] Perhaps you can provide me the same image to test with, I tried with some file I had available. Apart from different file, I did exactly same as you. You didn't specify whether you run that test under some webserver or using PHP CLI? ------------------------------------------------------------------------ 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
