httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Carrette <George_Carre...@iacnet.com>
Subject Re: Apache + mod_perl on Solaris
Date Thu, 31 Jul 1997 09:51:18 GMT
Rasmus asks:

>I recently convinced an extremely high profile site to move from Netscape ...

In the same boat, the Information Access Company Business Division
web sites were all Netscape + NSAPI (kind of a Fast CGI thing), but our
next product, a vertical market application for Sales Automation/Support
was being developed as Netscape + CGI Perl. With an eye toward
eventually going to Netscape + FastCGI + Perl.

But I did a review,  http://cpartner.iacnet.com/apache/perl.html,
and decided to have them use Apache + mod_perl.
Comments welcome on the review and build techniques used.

> Any serious caveats I need to address when I help these guys make the 
conversion? 

Yes, turn on perl warnings of all kind, PerlWarn On in the httpd.conf, but also 
use strict in
the actual scripts.

Then for final optimization we noticed (using /usr/proc/bin/pmap) that you gain 
massive
shared memory efficiencies by using the PerlScript command in the httpd.conf to
preload the script into the mother httpd process. If you have initializations 
such as loading
data files (we have lots) then you might as well do them as well.

Finally, in conversion of the cgi scripts it was in fact a real mess.

Things got into infinite loops quite easily at first. So that it was a must to 
protect the system
from massive memory allocations, using my Apache modifications 
here: http://cpartner.iacnet.com/apache/
I recommend setting reasonable cpu and memory limits on all production web 
servers.

And most cgi scripts are rather sloppy about managing state. We eventually moved
most of the variables that change values from one user transaction to another 
into a package named S.
And then reset it before processing:

  package S;
  reset 'A-Za-z';
  package main;


There were other minor problems with CGI.pm

But the resulting performance improvements were breaktaking, going from 0.300
seconds of cpu per request to less than 0.010 seconds, with no "real hard 
thinking work"
or performance profiling.




Mime
View raw message