Efficient intense image resizing

[Jim]

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?

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? Is there a
similar function which does run synchronously?

Finally, has anyone had any experience storing images in a MySQL DB
against storing in the standard file system? Much difference in
performance?

[Tim Van Wassenhove]

On 2005-07-30, Jim <ji***@yahoo.co m> wrote:

Finally, has anyone had any experience storing images in a MySQL DB
against storing in the standard file system? Much difference in
performance?

Well, a filesystem is specialized database for storing files.
Most people choose for an in-between solution:

- Store the files in the filesystem.
- Store the paths in the database (fe: mapping virtual and real fs)

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be >

[Nicholas Sherlock]

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).

If you are getting large volumes of traffic, you could create a system
where photos to be resized are added to a queue, then only processed at
a rate that doesn't affect the rest of the website. If you have control
over the thread priority of the resizing task, set it to idle or below
normal, then it only runs when the server has nothing else to do.

Cheers,
Nicholas Sherlock

[Raj Shekhar]

"Jim" <ji***@yahoo.co m> writes:

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.
I had used ImageMagick to resize images on a dual Intel Xenon
processor and found that the process was fast enough. Yes, the
process took up the CPU, but I the CPU did not get unduly overloaded.
If you have a slower processor, you will face problems.

The reason for not using GD libraries was that the server came with
GD1 and not GD2. GD1 did not have a few capabilities we wanted (true
colors, iirc)
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).
Serving pages, querying database backend are memory intensive
processes, not cpu bound processes.

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?

try to compare their outputs. Both of them take up CPU power.
Benchmark some images yourself using both the methods before going in
for any one of them. You can build your own Image class and then
change the underlying driver from IM to GD as your benchmarks
indicate.

--
Raj Shekhar
blog : http://rajshekhar.net/blog home : http://rajshekhar.net
Disclaimer : http://rajshekhar.net/disclaimer

[Jasen Betts]

In article <11************ **********@g47g 2000cwa.googleg roups.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

[Shawn Wilson]

"Jasen Betts" <ja*****@free.n et.nospam.nz> wrote in message
news:55******** ****@news.compa ss.net.nz...

In article <11************ **********@g47g 2000cwa.googleg roups.com>, Jim
wrote:

Finally, has anyone had any experience storing images in a MySQL DB
against storing in the standard file system? Much difference in
performance?

I too have had this question and have gotten basically the same response
from a lot of people. Storing images (or any binary data) in the DB itself
isn't generally recommended.

The first point they stated (pro-FS) was that the DB will serve your files
slower than the file system (most always - although I guess if your DB is on
a brand new quad cpu machine with SATA raid and the file system is on a 486
ATA-66 IDE drive then maybe not).

If the FS and DB are on the same machine, then the FS will serve your
content better, especially as traffic explodes.

Another point (pro-DB) was ease of backing up/restoring or transferring the
site. If EVERYTHING is in the DB, then all you have to do to move it or
restore it is insert a dump of your DB. If you put your binary data in the
FS, then you have to insert your DB backup, as well as FTP your files.

Personally, I've found that it's much more efficient to store large binary
data in the FS. I have had acceptable results with storing just a thumbnail
of an image in the DB itself, but not the full sized (2-5meg) image. The DB
wasn't horribly slow, but where the file system took less than a second to
serve my image, the DB took just over a second. For one client, it's a toss
up, but for 1000 hits a day, that'll get much worse.

-----------
Shawn Wilson