Scott Lamb wrote:
> - have a single GET request which takes way, way, way too long to
> respond - n_unprocessed_thumbnails*time_per_thumbnail >>> 0.1 sec for
> n_unprocessed_thumbnails=800, even if there's no contention for the
> processor
>
> - are forking from Apache, which is a bad idea, especially if it's
> multithreaded (are you using mpm_worker)? Big processes don't fork
> quickly. Much better to use a library to do this.
Hey Scott,
I did a test running convert, single processor and got the following
timing:
ImageMagick 'convert', 1 process, JPEG (command line)
real 8m35.515s
user 6m18.674s
sys 1m46.344s
Then I wrote a small PHP script that does the same thing (read
image, resize with constrain) and ran it through the command line, and
got this:
PHP, 1 process, JPEG (through PHP CLI)
real 36m17.260s
user 35m38.972s
sys 0m30.651s
Why oh why is it so much slower?! Is there something inheritedly
slow within PHP that causes it to be so much slower (which in turn
causes the Apache process to also take an incredible amount of time to
finish the same task)?
--
H | It's not a bug - it's an undocumented feature.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:ashley at pcraft.com> . 303.442.6410 x130
IT Director / SysAdmin / Websmith . 800.441.3873 x130
Photo Craft Imaging . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.