Sam Carleton wrote: > On 3/26/07, Issac Goldstand <[EMAIL PROTECTED]> wrote: >> 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, > > So if I understand you correctly, you are saying that CGI (I am really > leaning towards FastCGI if it isn't hard to setup) will work fine, one > request, one process, no problems. And you are saying that the use of > a proxy server is over kill? Joe's idea of sending a 404 when the > smaller image does not exist is interesting, is that basically what > you are suggesting?
Correct, although my idea was to have the script stat() the file and determine whether to generate content or not, while Joe's was to let Apache try to serve the file and generate it if it fails... Same idea, but different implementation. I think proxy is overkill, resource-wise; you're still just as vulnerable to "too many concurrent worker threads/processes" and have additional overhead of the back-end apache processes in addition. I'd personally go for a C/C++ module for Apache just because my strategy would be to optimize for serving the cached content, and from inside Apache, you can sendfile() the cached images - if the images need to be generated, you can do that either from inside the same module or pass that on to an system()ed process. I see it as a tradeoff: with a subprocess, you'll need to pay with the extra overhead of the additional process; however, with a module (either a C module for apache or fastcgi) you gain the overhead of keeping imagemagick in memory all of the time. Issac
