On Apr 30, 2007, at 2:56 PM, Ashley M. Kirchner wrote: > Actually, the way the vendor programmed it, we upload anywhere > between 4-800 images, then when someone goes to view that page, > that's when it creates the thumbs on the fly. Now, we're requested > this process be changed so that the thumbnails are created in the > background after uploading, so that when someone goes to view them, > they're already created and just pulled from cache. > > Funny how the vendor seemed to think that generating thumbnails > on the fly, all 800 of them, would take, according to them, 'a > fraction of second per image' - sure, when you have 3 images, but > not when you have 800 images. Ugh, yeah, that's...true if they generate the thumbnail on the actual hit for the thumbnail and they live in fantasy-land where only one person is browsing the site and that person's web browser asks for one image at a time. In reality-land, there will be multiple users and multiple simultaneous requests/user, so more outstanding requests than processors, so requests can get at best delayed an additional queue_size*per_image_time/n_processors, and more likely slowed even more than that due to thrashing. I could easily see hitting some timeout for individual GET requests as well as one for the total page. In your position after hearing that crap I'd tell them to keep the new image set hidden from users until the thumbnails are generated, to provide a progress bar to the uploader, maybe some indication of pending images in the interface for other admins, and probably to provide pagination to limit the images/page to a more reasonable number. And if I'm feeling particularly unforgiving, to launch n_processors low-priority processes/threads to do the work so that it completes quickly if the server is idle yet doesn't penalize user requests going on at the same time. (I'm not nice to vendors who say stupid things.) -- Scott Lamb <http://www.slamb.org/>