httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: apache module or CGI
Date Tue, 27 Mar 2007 07:10:56 GMT


Ralf Mattes wrote:
> On Tue, 2007-03-27 at 00:14 +0200, Issac Goldstand wrote:
>> Sam Carleton wrote:
>>> On 3/26/07, Issac Goldstand <margol@beamartyr.net> 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

Mime
View raw message