Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

mod_perl without separate config for static HTML?

by gunzip (Pilgrim)
on Oct 26, 2004 at 13:07 UTC ( [id://402559]=perlquestion: print w/replies, xml ) Need Help??

gunzip has asked for the wisdom of the Perl Monks concerning the following question:

It seems to me that Perl CGI scripts, these days, need to be run under mod_perl to match the performance of similar scripts written in, say, PHP. So, put the scripts under Apache::Registry. Fine so far. However, if the site has plenty of static pages I believe mod_perl also ends-up handling the static content unless configured to do otherwise (multiple servers/ports/IP addresses). Am I correct? Is there any way round this? If not I'll probably have to go with PHP for our current project because there are limits to how much we can play around with the server. Any suggestions? Does mod_php also handle static content in the same way?
  • Comment on mod_perl without separate config for static HTML?

Replies are listed 'Best First'.
Re: mod_perl without separate config for static HTML?
by Arunbear (Prior) on Oct 26, 2004 at 13:21 UTC
    mod_perl is only one option for speeding up CGI scripts. Is there some reason that you can't use FastCgi or SpeedyCGI ?
      Thanks for that. I hadn't considered them. Any preferences?
Re: mod_perl without separate config for static HTML?
by ides (Deacon) on Oct 26, 2004 at 13:38 UTC

    It is not so much that mod_perl "handles" the static content, it is the fact that the webserver processes are larger due to having mod_perl configured. If you say have Apache::Registry configured to work its magic on say /perl/ then it will only "handle" URIs that start with /perl/.

    That being said, I've successfully run fairly large websites (roughly 100,000 page views per day) on a site with mod_perl configured and contained a large amount of static content without any problems.

    Also, mod_php would behave roughly the same as it suffers from the same Apache server child bloat, granted not to the extent that mod_perl does.

    Frank Wiles <>

Re: mod_perl without separate config for static HTML?
by gellyfish (Monsignor) on Oct 26, 2004 at 13:53 UTC

    Its not strictly true that mod_perl is handling the static content, it actually only handles those resources that it is configured to handle, however the mod_perl will be loaded for every new apache process that is forked to handle a request whether the mod_perl will be used in the processing of the request or not, now because an apache with mod_perl has a larger memory footprint than one without it , if you are serving more static content than that handled by mod_perl you are going to get a lot of large processes which don't really need to be that big. To this end some people will run an apache without mod_perl on port 80 to serve the static content and a second one with mod_perl to serve the dynamic content - the first proxying the requests to the second where appropriate. Of course if the server is only moderately loaded (in terms of it's free memory, swap usage and so forth) you probably won't even notice much difference if you have a mnod_perl apache serving your static content or not.

    With Apache 2.0 and mod_perl in a threaded configuration the effects of the mod_perl loading can be mitigated by the use of "interpreter pools" whereby the perl interpreter is requested from a pool when mod_perl handles the request.


Re: mod_perl without separate config for static HTML?
by Mutant (Priest) on Oct 26, 2004 at 13:28 UTC

    If you can't configure Apache, your hands are kind of tied. The usual configuration of PHP is to only parse files with the extention of '.php'.

    There's probably not such a clear standard when running under mod_perl, but it's quite simple to configure Apache to only run files that end in say '.cgi' under Apache::Registry:

    <LocationMatch *.cgi> SetHandler perl-script PerlHandler Apache::Registry </LocationMatch>

    (That's probably not the most efficient way to do it, but with Apache TMTOWTDI :) Another alternative would be to put all your scripts into one directory and set the location to that.)

    If you're not really able to do much with the config (apart from the fact that you should be complaining to management that your work environment is preventing you from doing your job properly) the perfomance loss at having to run everything under Apache::Registry may be neglible, ie. it may not be enough by itself to swing the pendulum from Perl to PHP

      Are you saying that using a mod_perl file extension, eg. .mpl, configured with Apache::Registry will result in static content being handled outside mod_perl? I can mess with httpd.conf to this extent but I'm not in a position to setup separate servers/ports/IPs to separate static HTML requests from mod_perl so your solution may save me from going down the mod_php route. What are the inefficiencies you alluded to?

      Are you also saying that configuring a distinct /perl directory for Apache::Registry scripts will leave the static pages to be handled as normal? That's what I normally do anyway?

        Here's a fairly typical Apache::Registry config:

        <Location /cgi/> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI </Location>

        Now, everything under the 'cgi' dir will be executed under Apache::Registry, and everything else (assuming you don't have other 'Location' etc. directives setup) will just be static.

        You can even use the 'Alias' directive to make the cgi dir outside of your public directories (usually a good idea).

        The ineffeciencies I metentioned just refered to the fact that I was using 'LocationMatch' which might not be necessary for what you're trying to do.

        As someone else mentioned, look at the apache docs and mod_perl docs. Apache/mod_perl config is an art from in itself, and it's definitely something you want to have a handle on if you're worried about performance

Re: mod_perl without separate config for static HTML?
by gunzip (Pilgrim) on Oct 26, 2004 at 14:08 UTC

    Considering the enlightenemnt received so far I should modify my query thus:

    With Perl CGI scripts configured to run under Apache::Registry is the increased memory footprint of mod_perl processes also incurred in static content generation? As I understand it you need to isolate the 2 to get round this issue via separate servers/ports/IPs. Is FastCGI/SpeedyCGI therefore a better solution if you aren't using Apache::Request and have more static content than dynamic?

      A useful re-phrasing gunzip!

      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.


        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.

      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.


Re: mod_perl without separate config for static HTML?
by Mutant (Priest) on Oct 26, 2004 at 15:58 UTC

    The trouble is, performance isn't as simple as "X is faster than Y". It's a series of complex trade-offs. For example, mod_perl causes Apache processes to have a larger memory footprint. Depending on what you're doing, it may well be worse if you're running under Apache::Registry, especially if your CGI scripts aren't tuned to run under it. However, the execution time is generally far superior to CGI. In a lot of cases, it's better to use more memory than to run slowly.

    Of course, this is not always the case. It's all highly dependant on exactly what you're doing, what the goals of the project are, etc.

    There's a strong possibility that performance isn't as important for your application as you think. There isn't a huge amount of difference between the performance of mod_perl using custom handlers, mod_perl using Apache::Registry and PHP using mod_php, at least for the vast majority of applications. Unless your requirements specifically state 'X must run in n seconds or less', I wouldn't let performance be a huge factor in whether I chose PHP over Perl

      Performance isn't what my posts referred to. I take your point about the speed issue. It's the memory per process for static content that concerns me. If mod_whatever is adding a significant amount of memory overhead which is redundant for static content then that concerns me.
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://402559]
Approved by Arunbear
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-04-15 16:55 GMT
Find Nodes?
    Voting Booth?

    No recent polls found