mod_perl Web Development: Why We Use mod_perl For Web Development
April 3, 2008 – 1:43 pmmod_perl has always been the go-to choice for web development at UsenetBinaries.com, so our engineers thought they would share the reasons for that choice, and why we don’t use other popular solutions such as PHP or Ruby On Rails.
Here at UB, we process a massive amount of video and image files 24/7, and we serve them to a lot of users around the world every day.
When it comes to code, everything is about reliability and efficiency.
This is especially true for the front-end of the website, which we have painstakingly optimized over seven years to make sure you can browse Usenetat your speed.
Internally, we prefer mod_perl for the page processing on our websites. mod_perl is basically the Perl programming interpreter embedded into an Apache webserver process, so that there is no startup or shutdown time for your Perl programs - they are always ‘running’ in a process. It makes executing code run *much* faster.
Once you have the basics of mod_perl down, you can also apply a lot of other tricks - like importing a common template or complex data object into shared memory - which help speed everything up even more. Its very powerful and flexible.
All our engineers have had production experience with other web languages- Perl CGI, PHP, C - and even more intermediary in-house, third-party, and open-source development platforms which run on top of those languages - but we chose to stick with mod_perl for UB web pages. The reason for this is mostly extensibility, flexibility, and performance scalability.
mod_perl usage, 1997-2007 In this graph, we see mod_perl popularity falling off after 2003. One reason for this is that PHP has rightfully grown in popularity for a large percentage of web applications which previously would have been written in Perl. Another reason may be that webmasters are more savvy about cloaking mod_perl in their server signature, which makes accurate reporting impossible.
Prior to developing UB, our first UB engineer (we’ll call him Ash), worked with a massive custom C web platform, and it was a nightmare. Every developer had a copy of the entire codebase on his local system, and if Ash wanted to make sure his code was going to work, he had to update the codebase and do a fresh compile of all the other C code in the portal - this would take *hours*, plus a couple of emails and cube trips to other engineers to ask how to work around the compile error of the day generated by their code.
In addition, code for very simple procedures took longer to write (and significantly longer to test and debug) than in a high-level language like Perl. In-house C libraries shaved some of that work but were not documented and would occasionally break existing code when they were updated without warning. Some of the in-house libraries performed complex duties which were much better supported in Perl’s CPAN library. Certain parts of the organization would find the system so inappropriate for their needs that they simply used something else - including their own custom Java and Perl page-generating systems - creating a nightmare of engineering factions across the enterprise. Finally, there were the inevitable memory leaks and faults which come with every C system.
As for PHP - well, PHP is really attractive for web development as it is built from the ground-up for this purpose - PHP code can go up and be modified very quickly - but PHP delay budget (the time in seconds to fulfill a request) is a bear and takes a lot more work to get under control for heavy-traffic sites. Its also one of the least strict languages around, and doesn’t really enforce a lot of good programming behavior. Its libraries are good but not as good as Perl’s.
If we had slightly less stringent performance and scaling requirements, or if we had a larger engineering staff, we might have chosen to throw hardware and advanced caching at the performance issue and gone with PHP to reduce codebase complexity and make interface changes less involved.
Make no mistake - when we edit the PHP templates for this Wordpress blog, I wish our mod_perl code could all be that easy, but its not.
In exchange for this added complexity, we have very high-efficiency code which reduces the amount of hardware we need, the speed at which the average page loads, and has survived massive traffic events in the past which would challenge your local ISP.
Similarly, we have never been able to produce even PHP-level results with equivalent code in Ruby On Rails, which carries a massive amount of overhead and replaces efficient data handling with extremely simple data handling. Again, for the right developer and project, its a good choice for some. For example, if a developer was working on an intranet which required a wide variety of database views from a local (not internet) population, it would probably be an outstanding choice.
So, while everyday web development gets easier and easier with the advancements of platforms like PHP and Ruby On Rails, we’re good with mod_perl, have been for years, and probably will be for some time.
Feel free to let us know your opinion in the comments!
