Thumbnail script - high CPU load

My thumbnail script makes the CPU go crazy. What should I do?

[syff]

I'm using a slightly modified version of ImageThumb on my site, and although I've enabled caching it's currently way too CPU heavy, and consumes about 65-70% of the total daily load (!)

There are a lot of thumbnails on my website, and with 1000-1500 daily visitors I'm afraid the script is going to kill my server one day.

Reducing the amount of thumbnails is not an option.

I've tried looking for alternative on-the-fly thumbnail scripts, but they all seem the same to me.

What do you suggest I should do? Abandon on-the-fly generation with caching, and simply generate thumbnails upon uploading, or is there a way to modify ImageThumb to consume less CPU? Alternatively, does anybody know a different script that requires less resources.

All help is greatly appreciated.

Thanks!

[edited by: coopster at 8:55 pm (utc) on Mar. 26, 2008]
[edit reason] unlinked url [/edit]

[Duskrider]

Hey syff,

I had the same question when I designed an image-on-the-fly site. I decided to have the thumbnails created and stored on the server when the larger image was created or uploaded rather than try to generate thumbs each time they needed to be viewed. At first I had the thumbs created dynamically, but the wait time and server load just wasn't worth the relatively small amount of storage space I gained. I'm not sure how many thumbs you're talking, but the site I referenced currently has over 1500 images, each with it's own thumbnail, and I don't even notice the space missing.

My visitors probably appreciate it too when they're browsing and only need to wait for the image to download rather than be both generated AND downloaded.

[syff]

Thanks a lot for your quick reply!

Do you have any experience with a good thumbnail class (or something similar), that makes the process of resizing both already uploaded and new images quick and easy?

[penders]

I've tried looking for alternative on-the-fly thumbnail scripts...

I'm just curious as to why one would choose to generate thumbnails on-the-fly (when requested by the user) instead of generating and storing the thumbnail as a once off when the image(s) are first uploaded (when that is a possibility)?

[Duskrider]

My guess would be storage space... at least that's why I tried it that way first. There was also a 'cool factor', at least for me, to be able to say that I didn't store any images on my site at all. All my big images are procedurally generated at display time from smaller graphics according to database variables unique to each user, so I figured I could do the same for the thumbs and not need to store a single image anywhere. How 'cool' would it be to have thousands or even hundreds of thousands of users, each with their own unique image, yet not store a single image on the server?

Not cool enough, I'm afraid, to ignore the load it places on the server and the wait time it incurs on the browser. It's fine if you're only showing one image or thumbnail at a time, but if you want users to browse through multiple thumbnails on a page they should probably be stored on the server and ready to go. That way all they need is to be downloaded by the browser.

In any case, all the thumbnail generation code I have is from scratch using GD, so I'm not familiar with any ready-made classes, but I'm sure they exist. Thumbnail generation is a pretty common task.

[syff]

I'm creating an online community, and when I started the project I didn't know what different dimensions my pictures should have on the different pages.

Generating thumbnails on the fly certainly made coding much easier, but I quickly found out that it put the server through a lot of pain.

[whoisgregg]

There must be something broken with your caching mechanism... If the thumbs are cached, then the only overhead from your script should be a simple file_exists(), filemtime(), and fileread(). None of those take long to do and none of them should impact your CPU to that degree.

The other common trouble with dynamic image generation is not sending the right headers for the client to cache the image. It's possible too that the users aren't caching the thumbnails, so every time they load a page they have to go back to your server to get the thumbnails.

I've done these before, but always from scratch.