Re: [cgiapp] CAP::Apache and CAP::Session

[Michael Peters <suppressed>]

Cees Hek wrote:
> On Tue, 16 Nov 2004 17:10:08 -0500, Jesse Erlbaum <suppressed> wrote:
>
> > Performance benefits over Apache::Registry seem marginal when you
> > consider the total request time (network transit, database access, etc.)
> > OTOH, functionality takes a hit, as you are now seeing.
>
>
> Also, if the only part of mod_perl you are using is Apache::Registry
> for your perl scripts (or just writing content Handlers), then might I
> recommend PersistentPerl.  This allows your apache processes to remain
> small (mod_perl adds significantly to the memory requirements of
> apache), and also gives you the ability to group your CGI scripts into
> different process groups, giving you greater control over memory
> resource usage.

Ok, since everyone is bringing this up I just thought I would list the 
reasons that I would use C::A under mod_perl and not want CGI.pm involved.

+ speed - yes I know that in some circumstances CGI doesn't perform that 
badly under mod_perl since it doesn't need to be loaded again. I also 
know that a web application typically has other bottle necks besides 
parameter parsing and cookie generation (like database connections, 
large queries, etc). Even knowing this, If all I'm doing is using the 
Apache::* modules for dealing with parameters and cookies, why not use 
the solution that is faster. If I'm starting a very high performance 
project and I'm looking at C::A, the fact that things would be difficult 
to use the Apache::* modules would be a big turn off.

You can always throw more hardware at it right? But if with a simple 
decision to not use CGI.pm can be made and I can squeeze even just a 
couple of drops more out of my app why wouldn't I? I don't think that 
"it's not that much faster" is a valid argument in and of itself.

+ size - CGI.pm is a very large module (as others have pointed out just 
recently) and by not using it at all I save myself memory. This again 
would help in high performance situations.

+ more access to apache - I agree that in most typical situations all 
you do in a C::A is content generation. But I can think of other 
situations where it would be nice to have a more direct access to the 
apache API. You might want to register a clean up hook to handle stuff 
after content generation involving apache, or you might want to make 
changes to the logging mechanism, or anything else that you can do under 
mod_perl.

I realize that you can also do this under Apache::Registry even if you 
have CGI.pm through the Apache object. But now you have two objects that 
can handle headers, parameters, etc. Why complicate the issue with two 
modules that have that much overlap if you don't want to?

Now having said all of this I recognize that some people want to use 
CGI.pm (eg, HTML widget generation). I have no problems with that. I'm 
not trying to convince anyone to abondon it. I just think that it 
hampers the adoption of C::A for some when becomes difficult to use the 
apache API. I think we can come up with a way so that everyone is happy. 
Maybe the best I can hope for is that my plugin doesn't work with every 
plugin that uses CGI.pm specific features.

--
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed