In my 'server farm' (23 machines) we have machines running mod-PHP and mod-Perl. mod_perl/Apache::Registry type code, or typical CGI style code if you prefer, is about as fast on a mod-Perl machine as PHP code is on a mod-PHP machine. Carefully crafted mod_perl (i.e. Handler) code can be marginally faster to very significantly faster due to the tight integration with Apache.

In both environments the speed for serving static pages is about the same.

Adding a second Apache to a machine with httpd.conf tailored for static serving does give a marked improvement in serving truly static pages. However their is one wierdness we have yet to explain - if you run a second Apache for serving static pages on a mod_PHP machine the benefit is not as great as running it on a mod-Perl machine! Go figure. So we have a client with some big mod-Perl and some big PHP where we run two machines for him. Both machines have a second, identically configured Apache but we use the mod-Perl machine to serve the static pages for preference. He only uses the second Apache on the mod-PHP machine for developers usually.

Now, I don't claim to be an expert - we have a hired gun who comes in to configure and manage servers for us - we got into this because we have a rack in a big carrier neutral facility so we offset some of the costs by offering colocation.

jdtoronto

So, if your site's content is mainly static it would appear that bog-standard Perl CGI or PersitentPerl would be a better option for scripts since they don't affect the size of the httpd process used for serving static content.

It's only a better option if you don't care about the performance gains from mod_perl.

It's not hard to run the sort of proxy setup that the page you read in the mod_perl guide recommends. However, the purpose of that is increasing scalability. Most sites don't need scalability because they hardly get any traffic. Don't fret about this kind of thing unless you expect your site to be relatively large in terms of numbers of concurrent users.

FWIW, mod_php has the same issue with process size if you run it with a code cache (sometimes called an accelerator). If you run it without one, it's slower than mod_perl.

No not necessarily, it really depends on what your concerns are. If, as it appears is the case, you are stuck with a mod_perl enabled Apache then you are going to have much the same size of httpd process anyway so you might as well use the mod_perl to handle the dynamic content, you can monitor the load on the server and tune the configuration (as I mentioned earlier) but if you have mod_perl already loaded then it will have no impact on the handling of static content whether you use it or not.

I'm beginning to think that you might be better asking these questions somewhere more specifically concerned with apache configuration issues.

/J\

Bottom line:

If you run mod_perl OR mod_php on the same config that your static pages are served from, you will have apache processes that are larger (and therefor you can run fewer on the same hardware/memory) and that can effect your static page serve rate. If static serve rate needs to be balls to the walls fast, you have two choices. 1) Dual install apache and limit how many of the apache processes are running mod_perl (only the amount needed for the mod_perl page serve, in your case few) and the static site (only serves static pages -- highly tuned config). 2) run the static content off another server.


-Waswas

When your apache is started it will initially fork a number of children to handle requests (the number is determined by the StartServers configuration directive). Each one of these apache processes will be pretty much the same size and will have the mod_perl loaded, the size of a process that has actually handled a mod_perl request may increase significantly if the perl program loads some modules or has a lot of package data. These processes may then go on and handle static content. So yes initially the size of the processes is always the same but may increase depending on what they do. If you are concerned about the processes that have handled a mod_perl request growing large then you can use the  MaxRequestsPerChild configuration to limit the number of requests a process will handle before it gets reaped and possibly replaced by a new child (see also the MinSPareServers and MaxSpareServers in relation to the behaviour). Of course an Apache which has FastCGI compiled in will behave in exactly the same way except perhaps the memory usage may be different depending on the size of the module.

/J\