|
|
Posted by Jasen Betts on 11/15/74 11:24
In article <1122737220.848907.303500@g47g2000cwa.googlegroups.com>, Jim wrote:
> I've heard that resizing images through PHP (either GD2 or ImageMagick)
> is a processor intensive exercise. I'm setting up a site where users
> will be uploading up to 10 images along with the details of their
> product. For each image uploaded (max 500Kb), I'll be resizing it to
> create a small, medium and large version after which I'll discard the
> original. My worry is that as the site becomes more popular, the
> processor time spent resizing images could badly effect the other areas
> of the site (viewing/searching products).
>
> Has anyone got any experience implementing a very high traffic site
> where images are uploaded and resized? Any advice?
hard drives are cheap resize and store the scaled images and serve the
differently sized images from the files.
> I saw somewhere on usenet a comment that using exec() to launch
> ImageMagick to resize was quicker than using the PHP GD2 or ImageMagick
> API, anyone had any experience of this? I would have though that either
> way, the Apache thread dealing with the PHP script still has to wait
> until the function call or the call to exec() has finished or is this
> not the case? Does the exec() call run synchronously?
sometimes. especially if you have two or more processors...
recently I did some resizing (etc) using the netpbm suite of tools,
I've not timed it to see if it's faster or slower than image magick.
> Finally, has anyone had any experience storing images in a MySQL DB
> against storing in the standard file system? Much difference in
> performance?
that depends to some extent on the standard file system. I would expect
the file system to be faster as apache is well optimisied for serving
static files...
--
Bye.
Jasen
Navigation:
[Reply to this message]
|