Back from the wilderness (and musings about Perl)
I’ve spent the last week away, where I’ve had absolutely no Internet access at all. No WWW, no RSS, no email – not even any Twitter (although I did tweet a couple of times from my phone). It’s surprising (or not) how much “connected” time I’ve got used to – it was like a week out of time, not even knowing the news (the only TV I get to watch these days is CBeebies…)
I was just catching up on my email/RSS backlog when a thread (you’ll probably have to join the group to read it) on the Perl Mongers LinkedIn group about Perl caught my eye – especially as the participants were talking about Perl CGI/FastCGI/mod_perl.
Bottom of the heap came Perl/CGI – somewhat unfairly, IMHO. For me, there is a time and a place for Perl/CGI – although it needs the entire Perl process set up and the script interpreted for each call, it’s perfect for the occasional hack and/or stuff that’s still in active (prototype) development stage. Not having to restart/reload servers to make changes visible can be a big plus when you’re sat there with the client/end-user – you get the feedback, hack the code, hit refresh. Of course, once you’re done (and especially if the script is going to be public facing and get some hits) you should probably redevelop it into something more “solid”, but for the one-off script it’s the quickest and easiest path.
FastCGI seemed to be well received as a solution. Now, I’ve only just started looking into it, and I didn’t get much done last week, but my (current) understanding is the the “script” is interpreted and runs as a daemon, accepting the requests at a handler subroutine. Because the interpreter is persistent, there’s no setup or interpretation delay for each call, which makes it quicker than Perl/CGI. The number of child handlers (and so resource usage) can be controlled by the process, which makes resource allocation easier (for the reason that…) As the Perl FastCGI “server” runs separately from the HTTP server process (communicating using sockets), potentially as a completely different user, security (and resource allocation, as per the previous point) is easier to manage. You can use TCP/IP sockets for the FastCGI “server”, which can allow you to split the stack even further into “application servers” (running the FastCGI app) and “front-end HTTP servers” (which can just proxy to the application servers). With a mix of static and dynamic content, you can easily see where you need to beef up your servers – static stuff will hit the HTTP servers, dynamic stuff will hit the application servers. Throw in checks by the front-ends to make sure they’re getting the data (potentially trying all of the applications servers in turn until it can get one that can actually server the request) and you’ve got the recipe for a site with pretty good availability. The only fly in the ointment here is that the FastCGI “server” needs to be reloaded each time the code changes – not so bad if you have got the front-ends doing availability checks.
I’ve left mod_perl to last, for a couple of reasons. I’ve been using mod_perl on extremely busy sites for several years now, I don’t consider myself to be any kind of expert with it, but it’s served me (extremely) well. It has its pros and cons, and so far the balance has tipped in mod_perl’s favour – I guess I’m just used to the caveats. mod_perl, like FastCGI, only interprets the Perl code once per worker (thread/fork), so you get the same speed increase that FastCGI affords. The mod_perl stuff though, as its name implies, is kept within each worker, so the memory usage of each thread/fork does go up, and everything runs as the same user as the Apache HTTP daemon. mod_perl code can also be tightly coupled to the Apache HTTP daemon, making it harder to migrate in the future, but it does allow for some pretty low-level (in terms of protocol) access. Changing the code does require a reload of the Apache HTTP daemon (although a “graceful” one works fine, and is not so intrusive to the visitors) but you can pre-load a module that automatically checks for changes and issues the reload for you (useful for “staging” servers between development and live).
Now, the real fun comes/came when someone said:
If you evaluate mod_perl, you’d be evaluating something from an ancient world that is really an inferior solution. Most large scale Perl systems are using FastCGI.
“something from an ancient world” – well, mod_perl is (AFAIK) still being developed, and I still see it appearing in HTTP responses, so I wouldn’t consider it ancient.
“inferior solution” – guessing this is compared to FastCGI. There are some obvious benefits of FastCGI over mod_perl, there’s no doubt, but mod_perl’s tight integration with the Apache HTTP daemon allows it to do stuff that FastCGI couldn’t. So, claiming one solution is inferior to the other isn’t really fair.
And the “Most large scale Perl systems are using FastCGI” claim just screams for a “”. No evidence was provided for this claim, and it’s a pretty bold one to make – even qualifying it with an “IMHO” would make it better.
Other people in the thread say that:
I’d argue that mod_perl is not so much antiquated as just “out of vogue”.
Now that amused me quite a bit. Perl itself is a bit “out of vogue”, hence stuff like the Planet Perl Iron Man challenge to raise its profile a bit, so for mod_perl to be described as “out of vogue” (even amongst the Perl community) is a bit of a kick for it. 🙂
Original post “hit back” with:
mod_perl certainly isn’t dead, and it is a very viable solution if you need an API into the webserver itself (which ties you to apache). If you don’t need that, mod_perl is a really poor solution.
It’s fallen out of grace because of its own demerits, and hasn’t kept up with modern technologies.
More bold claims. I haven’t experienced any of that myself (apart from the tie to the Apache HTTP daemon), and I fail to see how mod_perl hasn’t been able to leverage CPAN to keep up with “modern technologies”. Maybe I’m missing someone more fundamental in that claim (like the internal coding of mod_perl)…
The fact that Catalyst already has support for running as FastCGI, and that I’m looking to refactor some code into a something that’s more manageable, my “move” to FastCGI should be quite interesting (not least of all because I’ll have performance metrics from the mod_perl versions to compare against). As part of the (greater) system also has PHP code, it’ll be good to have a single “acceleration” platform for both (rather than running both mod_perl/APC).
So, where do I stand? I’m using mod_perl, I’ll probably carry on using mod_perl for some time, but I can also see that the FastCGI route also has some advantages that I’m interested in exploring. I’m also going to keep hacking Perl/CGI scripts as well, probably just out of spite. 😀
This site uses Akismet to reduce spam. Learn how your comment data is processed.