Gee, it's huge

If you've previously compiled an Apache server you may have noticed that the typical httpd size is between 300-400K. Now, with mod_perl integrated, the httpd has ballooned to over 1 megabyte. Perl is, you can see, as William Shatner would shill, "big! really big!". This brings us to the subject of tradeoffs.

Life is a box of compromises. Buffalo wings and cheesecake are a swell meal, but make you fatter. Chicken broth and celery stalks are slimming and dull. And so it is with the Apache web server, which is much more robust with a belly full of Perl. The trouble in the henhouse is that Apache, as we discussed, is pre-forking -- which means that a fat parent server will spawn fat children. Several of them. Isn't that always the way. That's the cost of doing business when you want to execute heavy Perl scripts with aplomb, but most web sites are composed of more than simply Perl scripts -- such as static web pages. And a static web page is like a sheet of paper, lightweight. Unfortunately, if your site is running mod_perl and has many static pages to serve in addition to Perl scripts, that is one fat child process running around carrying a tiny load.

So it's a battle of inefficiencies: vanilla Apache is inefficient at executing Perl scripts via CGI, while mod_perl beefed up Apache is inefficient at serving simple web pages. You need to consider the general breakdown of pages served by your site -- are we looking at 90% Perl scripts vs. 10% simple pages, or 10% Perl scripts vs. 90% simple pages? Likely somewhere in between. At the extremes, your best choice is to choose the most efficient server for most of the time. In a scenario where 10% of your requests trigger Perl scripts, it might be justifiable to live with the relative penalty of CGI for the benefit of a small and compact server process, allowing for more simultaneous visitors in a given amount of memory. If you serve relatively few simple pages, the advantages of a beefy mod_perl server will pay off more than the penalty of a few extra though large processes. Many readers find themselves somewhere between these two poles, though -- say, 30/70 or 40/60 or 50/50.

A nifty solution to this quandary is to run two Apache servers. One Apache server is the small, compact vanilla version while the other is the robust and hefty mod_perl enabled Apache server. Incoming requests are then routed to the mod_perl server when Perl scripts are required, while simple page requests are handled by the lightweight server. Elegant enough, but the devil is in the details. Ultimately, this is the preferred solution when you can't justify serving all content from either a slim or fat Apache server but it has its own pitfalls. You'll need to maintain two separate installation trees for each Apache server, including separate configuration files, and each server will spit out separate log files, making the job of analyzing traffic a bit more complicated. The mod_perl server is typically configured to listen on an alternate network port, such as 8080, but you don't want end users to see this -- all pages should appear to come from one server lest problems arise with firewalls, bookmarks, and so on. This is solved by employing internal proxying within the slim Apache server's configuration file, to redirect requests for Perl scripts to the mod_perl server "behind the scenes". That's the short of it -- the long is simply too long and too off-topic for this article, but we again direct you to Stas Bekman's thorough coverage of multiple server arrangements.

Getting the Goods
The Perl You Need to Know
Basic Configuration