I'd say then that you need to do in on-the-fly with caching. Caching should be pretty easy - just have a static algorithm for determining the name of the cached image and stat it to see if it already exists. If so serve it; if not, reduce the image, save it and then serve. You don't need a separate process if we're dealing with foreground processing.
Issac Sam Carleton wrote: > On 3/26/07, Issac Goldstand <[EMAIL PROTECTED]> wrote: >> If the images are already on the server, and needed for the response >> immediately, you'd need to do it inline, but you could still make life >> easier on yourself (somewhat) by caching the reduced images to avoid >> reprocessing. >> >> I could give more specific advice if you could share a bit more about >> what you're trying to accomplish in general. > > Issac, > > It is beyond simple. There are a bunch a full size image (4 MB to 16 > MB) on the web server that need to be indexed (210x140 size) on the > browser, when the user clicks on a thumbnail, they need to get a > larger (900x600 size) image to view. They are getting any where from > 12 to 96 of the indexed images per page. > > Like I said above, I fully understand the importance of caching the > results. Rather then trying to write the code myself and save the > images myself, I am using a second instance of apache running as a > reverse proxy to cache the results;) Why reinvent the wheel;) > > On thought I had was this: > > When the server gets the request for the image, if it does need to > downsize it, add it to a queue and simply make the system wait for the > response. I would actually have to create some type of pool of > processes so that things don't get too back logged. I am thinking > maybe based on IP address or something so that there is only one > downsizing per browser. The only issue I have there is what happens > if two browsers request the same image, I am sure there is a way that > once the image is downsized once, it could be sent to both browsers, > but this is starting to get really complex. I am really looking for > simplicity. Speed is important, but this is really only a very small > piece of what I am doing. > > Right now, the worst and very much extreme case is 100 viewing > stations (browsers) having access. Normal is going to be between 4 > and 20 viewing stations. > > Sam
