mod_perlite helps Perl gain ground in the PHP arena

| 8 Comments

Michele Beltrame wrote in about the mod_perlite project, which I'd love to see take off. mod_perl has never been easy to install, and ISPs and webhosts are loathe to use it for security reasons. mod_perlite would provide easy access to Perl without the weight of CGI.

mod_perlite is an interesting Apache module currently under development. I'd say it's the equivalent of what mod_php is for PHP: a fast, easy to use, and relatively safe way to use Perl scripts for the development of small and medium web applications.

A project like this brings Perl back into play as a good choice in a field currently dominated by PHP. In particular, PHP is great when you need to run a lot of different small applications on the same web server, and you want all of them to run fast enough. CGI is slow compared to mod_php because both the interpreter and the application need to be loaded for every single request. Solutions like mod_perl and mod_fastcgi are the best solution when you have a few big applications, but they're not a good choice in this scenario, because they keep the application resident: when you've got so many small applications (which, in most cases, are invoked infrequently) you end up with enormous memory footprint.

mod_perlite is the winner here: only the interpreter is kept resident (there's also the idea to keep some modules loaded, which might speed up things further) and applications are loaded at request time. This also helps avoid problems with memory leaks. Using mod_perlite is simple: just configure Apache and all the .pl files will run without modification taking full advantage of mod_perlite and therefore reducing execution time to a fraction.

Unfortunately the module is not yet stable, as there's still work to do. My installation on Gentoo Linux x86_64 went smoothly. mod_perlite works but still suffers some major issues. In fact, at present it's only usable for very simple applications because of a bug in how query parameters passed by Apache are handled.

To make mod_perlite fully usable, the project web site has a three point TODO list:

  • Fix form POST processing ('read' does not work reliably)
  • Limit Perl running time.
  • Find ways to cache code.

The project is looking for help, so if you are interested and know something about mod_perl, writing Apache modules in C, and about overriding system calls in Perl - and if the project seems interesting to you - please shout!

And... if someone argues "we're 10 years late compared to PHP", I'd reply "better late than never". ;-)

Michele Beltrame lives in North-Eastern Italy, where he has been developing web applications in Perl since 1996. He is an active member of the Italian Perl community and of the Italian Perl Workshop organizational committee. In his free time he publishes guidebooks on the mountains surrounding his area.

8 Comments

I don't want to rain on the parade, but this article is full of incomplete or inaccurate information.

  • There is nothing easier to install about mod_perlite than mod_perl of mod_fastcgi.
  • It's easy and cheap to get a virtual server with root access that allows you to run mod_perl.
  • Support for FastCGI is widespread at cheap ISPs and suitable for almost any perl application.
  • Configuring mod_perl with "MaxRequestsPerChild 1" is almost identical to what mod_perlite is doing and already provides the ability to do module caching by loading things during startup.

Hello!

It's not really a parade... more of a post regarding a nice Apache module. ;-)

> It's easy and cheap to get a virtual server with root
> access that allows you to run mod_perl.

Yeah... I think I can see the average web designer who does some scripting having to deal with root access and install Apache modules. ;-)

The point here is that this designer/scripter can get an FTP account on whatever provider runs mod_perlite and just upload his scripts - which is exactly what PHP users do.

> Support for FastCGI is widespread at cheap ISPs and
> suitable for almost any perl application.

It's common for providers to have 200 or so (low-traffic, mainly) web sites on a single server, and all of these have all some dynamic news or so in PHP: the server is able to handle them perfectly.
Now, if I had 200 resident FastCGI applications, the server wouldn't be able to handle all of this anymore - mod_perlite is ideal for situations like this.

> Configuring mod_perl with "MaxRequestsPerChild 1" is
> almost identical to what mod_perlite is doing and
> already provides the ability to do module caching by >
> loading things during startup.

Does this solution keep memory space completely separate between different applications, like mod_perlite?

Anyway, I'm really not wanting to start some fight, but I think mod_perlite is really ideal in certain situations where PHP is currently used a lot. OK, in others it is completely useless... er, like PHP is. ;-)

Michele.

I think you're assuming a uniformity of configuration for both PHP and FastCGI that isn't realistic. Some ISPs run PHP through mod_php while others run it through FastCGI or even plain CGI. Scalability of PHP support on different ISPs differs dramatically.

Moreover, FastCGI will see something like a Catalyst or Mason application as a single app, no matter what action is requested within it. It doesn't need to keep separate processes running for every URL handled by the app.

The mod_perl configuration I mentioned keeps everything (at least everything loaded after startup) separate and avoids all issues of persistent variables because it kills each process after a single request. It's not a configuration I would recommend with FastCGI so widely available for low-end hosting, but it's useful if you have mod_perl and don't want to write clean code. It's also useful as a dev setup, which I'll write more about in a PerlMonks article later.

In my opinion, it would be more useful to spend energy on making FastCGI easy for newbies to use than to try to convince all the ISPs out there to install a new apache module.

I'm actually quite intersted in mod_perlite since project goals seem to overlap with Mojo quite a bit. (we even added a pure perl fastcgi implementation to make deployment easier for average users)

Is the mod_perlite api documented yet so we can add a binding? Oh and you might want to update the github repo, last commit there is from early february.

Hi Sebastian!

> Is the mod_perlite api documented yet so we can add a
> binding? Oh and you might want to update the github
> repo, last commit there is from early february.

I'm not directly involved with the development of mod_perlite: I just try to spread the word a bit so, if there is interest, the project can get some good help.

For additional discussion you'd better post in the project mailing list:

http://groups.google.com/group/modperlite

Michele.

If you compare prices for virtual servers with root access and PHP hosting, then you'll see the problem that mod_perlite tries to solve.

There are many people for which that difference matters, and influences the choice of programming language.

Virtual servers with root are very cheap, but servers with FastCGI are even cheaper. You can get them for less than $10 a month. There's no significant price difference between Perl on FastCGI and PHP.

The point is not cost, but ease of installation and maintenance by novices. Everything you've stated is absolutely true if you know what you are doing or are motivated in figuring it out. Most end users[1] aren't and simply opt for PHP because its less hassle for them.

From my understanding this work does not have to be an Apache module. If there is a way to architect the concept as a FastCGI process like PHP can run then great. Join in and make fire away.

No matter how much better Perl and software written in it is, it will always lose ground to anything that is easier to run and just good enough.

<tim/>

[1] This effort was spawned by a need of the MT community.

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.