[CentOS] Slow performance

Mon Apr 30 22:39:35 UTC 2007
Scott Lamb <slamb at slamb.org>

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/>