Ralf Mattes wrote: > On Tue, 2007-03-27 at 00:14 +0200, Issac Goldstand wrote: >> 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, > > Yes, but be careful: a simple stat won't be enough - you might end up > serving partially generated content.
Good point - to get around it, you can write the image to a tempfile on the same partition and then just change the filename or move the file (or hard link the inode to a new file and then remove the original) - that should gie you a more atomic write. > >> 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 > > This is a very important point: sendfile is an excellent performance > optimization, esp. if you predict that an image is served much more > often than it's generated (and iff not you might not bother to cache > anyway). > >> - 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; > > and 5-7 more file descriptors ... that's part of the "overhead" I meant. descriptors, a bit of ram, cpu cycles to fork and then exec, etc > >> 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. > > Well, on most OSs that's rather cheap. Shared objects are mapped only > once and shared between instances. No need to worry. He said he was going to static link it, so IIRC, it's not going to share the code between processes... > > Cheers, RalfD > >> Issac
