http://qs1969.pair.com?node_id=738066

chromatic has posted a provocative piece CGI is Dead; mod_perlite is Alive! over at perl.com.

The executive summary says "There was no single, simple way to run and deploy persistent Perl web applications in the easy upload-and-go fashion epitomized by PHP. Many people saw that. Byrne Reese and Aaron Stone did something about it. Their project, mod_perlite, is one of Five Features Perl 5 Needs Now."

The money quote for me is this:

"
solutions that have emerged to try and address some of the limitations of CGI have grown too complex to solve the 80 percent of use cases out there: which is stated simply as, "I need a stateless and fast container to run my Perl script.

Aaron: With just upload and run simplicity.

Byrne: Yeah.

Aaron: That's something that competing languages -- well, not always competing, but other languages out there in the ecosystem that have the "upload and run" capability that is really tremendous for the long-tail of individual, personal and small business deployments, not to mention the experimental deployments within a company where you have the secret engineering web server where engineers have the liberty to test out new applications without having to devote so much time that their managers might notice they're doing something besides what they've been assigned. "Upload and run" simplicity is important for those skunk works projects where a lot of new ideas can be explored quickly and easily with Perl."

I haven't tried this, but the whole post is worth a read. As far as I'm concerned, the closer any tool gets to "upload and run simplicity" the better.

Replies are listed 'Best First'.
Re: What is mod_perlite?
by tirwhan (Abbot) on Jan 22, 2009 at 10:11 UTC

    I've just reread the article, as well as the mod_perlite homepage and some early discussion threads on the subject. I have to say I still don't get what the main point of mod_perlite is supposed to be. Since quite a few people whom I highly respect seem to be excited about the subject I'll try to summarize what I think about mod_perlite's proposed benefits and maybe someone can point out to me what I'm not seeing.

    Ease of deployment

    I understand that mod_perlite is trying to be more user-friendly than mod_perl, but AFAICS it's not competing with mod_perl at all, but rather with CGI and FastCGI, both of which are easy to deploy. It will be extremely hard for mod_perlite to be easier to set up than these two. Besides, the main target for mod_perlite seems to be the mass virtual host market for which the setup is highly automated anyway, so introducing another variation will just mean their admins need to change their scripts.

    Performance benefit over CGI

    As pointed out in my original question/objection on the subject, the time it takes to load and set up a new perl interpreter instance is dwarfed by the time it takes to load and compile even a simple module. mod_perlite does not cache modules between calls, so these will have to be loaded and compiled on every call (just as with CGI). In fact, the article states that mod_perlite will reinitialize the perl interpreter on every call (for security reasons, which make sense to me), so the benefit of having it preloaded into memory will be even smaller.

    I was recently involved in a discussion here on the benefits of forking a preloaded perl instance versus creating a newly instantiated process (different problem domain, but somewhat comparable). But again, the benefit that I pointed out at the time (COW memory) does not seem to apply to mod_perlite, modules will be loaded into newly initialized memory space every time. The only benefit that mod_perlite seems to offer is that of loading the perl interpreter from disk into memory. Since (on any moderately loaded server without severe memory problems) the interpreter will be sitting in the OS's disk cache anyway this seems like a minuscule benefit.

    So I'm left wondering, where is the performance benefit of mod_perlite supposed to come from? Have any benchmarks been run comparing mod_perlite to CGI which show a clear advantage?

    Performance benefit over FastCGI

    ?? . I don't see where even theoretically mod_perlite would offer something that FastCGI doesn't.

    Summary

    The article mentions some directions mod_perlite wants to explore in the future (like making a list of "safe modules" which do not need to be recompiled on every server call), which sound interesting and may be worthwhile in the future. But at the time this article was written these seem to be mere thoughts, none of them have been even tentatively explored.

    What am I missing? If this is really a feature Perl 5 needs now there must be some clear advantages available from it now, right? What are those advantages?


    All dogma is stupid.

      I would think that the benefit over FastCGI only comes in a few cases -- if you have _lots_ of CGIs on the system that only get called rarely, then there isn't the memory overhead for each individual script (and all of its included modules, etc.)

      It's possible that there might also be a benefit to hosting companies in terms of supporting it ... like when a script starts going wonky and you have to explain how they've not bothered initializing their variables to zero / empty / whatever, or something else is sticking around and not getting cleaned up. (memory leaks, accidental closures, etc.)

      As for the performance benefit over pure CGI -- I'm guessing that it only comes if the cost of reinitializing the interpreter is cheaper than loading in the first place -- if they can get the reinitializing cost down, then they'll improve performance of systems using this module.

      My understanding is that mod_perlite would be a direct alternative to PHP. It would let you put perl code into your HTML files, which you could then upload to your shared-host web server (assuming they provided support via a mod_perlite apache module, similar to mod_php) and it would "just work".

      Ideally, this should provide better performance that plain perl CGI, because the perl interpreter would only have to load once, when the web server starts up (just like PHP).

      It would not be as powerful as mod_perl, but this is in some cases seen as a "good" thing because many (most? all?) shared-host web site admins see it as a security risk and thus don't provide it.

      As a potential "PHP killer", mod_perlite has a lot of catching up to do. Most perl programmers have a low opinion of PHP and see it as an inferior programming language, and would be happy to make the switch if such an alternative were available. But I think PHP initially grew in popularity because it was considered easier to learn - a kind of "dumbed down" version of perl that non-programmers/hobbiests could use to quickly make "kewl" web pages, etc. So the notion that perl is "hard to learn" will probably remain a barrier to new user adoption.

      IF the implementation hurts performance (equal or better to PHP is an obvious "must have") or IF it allows any security leaks (thus spooking would-be hosting providers) then it will never get off the ground. But I think it's a cool idea and would really love to see this succeed.

        It would let you put perl code into your HTML files,

        Where do you get that from? You can of course already do this today (assuming you use a module like Template::Toolkit or Mason), but that has nothing to do with the Apache module backend, it's a language feature. I don't believe mod_perlite has anything to do with templating.

        One of the reasons (I think, this is far from my main area of expertise) that mod_php offers better performance than CGI is the fact that things Perl has as modules (e.g. database drivers) are compiled into mod_php itself (that also makes mod_php a pain to install on less popular platforms, but that's not my point). So one thing that may improve performance would be to load modules at Apache startup time (which, as perrin pointed out, you can do in mod_perl and FastCGI), but I don't see that as being a major design goal of mod_perlite. And since their approach is to reinitialise the perl interpreter on every request they would conceivably also have to reload modules, thus removing much of the benefit.


        All dogma is stupid.
Re: What is mod_perlite?
by perrin (Chancellor) on Jan 22, 2009 at 15:37 UTC

    I'm sorry to say it, but I think these guys are on the wrong track. To get the environment they're trying to build in mod_perl, all you have to do is set MaxRequestsPerChild to 1. Then the processes exit after one request and you get a fresh, pre-forked process with a pristine Perl interpreter for the next request. You can do something similar with FastCGI, and FastCGI already has the wide availability in cheap ISPs that they say they want. In fact, mod_perl even already has the feature they want with blessed modules that stay in memory: just load them in startup before forking and they will be there already compiled, even with the MaxRequestsPerChild approach.

    Why does no one do this with mod_perl or FastCGI? Because the performance is pretty bad compared to letting your code, database handles, and cached data stick around between requests.

      To get the environment they're trying to build in mod_perl, all you have to do is set MaxRequestsPerChild to 1.

      Except that mod_perl is still a single global environment for all Perl programs such that one customer's global changes could overwrite another customer's global changes.

      If the "correct" solution to that is "why don't you just give each customer his own private server?", then mod_php still has clear superiority over mod_perl in the $4.95/month hosting market. I believe Clayton Christensen wrote authoritatively about the dangers of ignoring that.

        Except that mod_perl is still a single global environment for all Perl programs such that one customer's global changes could overwrite another customer's global changes.

        That's true for server config changes, but not for anything you can do after server startup (i.e. without root). When you set MaxRequestsPerChild to 1, everything is gone at the end of each request.

        I don't see any need for mod_perl to compete in the hosting market when FastCGI is already ubiquitous, and has this same capability. (The Ruby hype was good for something after all!) I think these guys should have taken a closer look at FastCGI before they decided that cheap hosting was a problem.

        'If the "correct" solution to that is "why don't you just give each customer his own private server?", then mod_php still has clear superiority over mod_perl in the $4.95/month hosting market.'

        I see your point, but I don't think that the term superiority can be applied to solutions in the $4.95/month hosting market. I'd say that for $4.95 a month, a user would be lucky to get a functioning anything.

Re: What is mod_perlite?
by Your Mother (Archbishop) on Jan 22, 2009 at 06:44 UTC

    I'm actually pretty excited to see what will come of this. To my mind, this is the only thing PHP ever had going for it but it was the right thing at the right time and it's why Perl doesn't occupy that niche. I like mod_perl plenty but it's just not suited to shared hosting and budget hacking. mp2 was, IIRC, supposed to address some of that but it seems it was too difficult/complicated for typical hosts to deploy or the functionality didn't pan out. I don't know enough about it. Maybe perrin or another mp guru could elaborate on that. :)

    If there were a stable, easy-to-deploy, shared environment friendly way to get Perl into the mix I think we'd see a pretty major power-shift in the small-business/personal-website game over the next few years.

      If there were a stable, easy-to-deploy, shared environment friendly way to get Perl into the mix I think we'd see a pretty major power-shift in the small-business/personal-website game over the next few years.

      I know that I, personally, would switch to a Perl solution for my personal website if the difficulty curve for upload and run dropped even to twice that of PHP. Sadly, I haven't found that to be the case, thus far.

      for(split(" ","tsuJ rehtonA lreP rekcaH")){print reverse . " "}print "\b.\n";
Re: What is mod_perlite?
by tilly (Archbishop) on Jan 22, 2009 at 17:20 UTC
    I have to agree with perrin. They have removed the need for a new process, OK, but they are initializing a new Perl interpreter for each request, which means that they have to initialize anything they need in Perl. This is entirely inappropriate for a busy website.

    In short their solution is like Apache::PerlRun, only worse.

Re: What is mod_perlite?
by ELISHEVA (Prior) on Jan 28, 2009 at 05:36 UTC

    It strikes me that Byrne and Aaron might just pull this off because they really believe in themselves and they are addressing a real problem, even if they are going about it the wrong way.

    The problem, as I understand it, is this: CGI is too slow and mod_perl doesn't have a simple set of configuration options to give each virtual host its own isolated copy of perl. Furthermore, whether using CGI or mod_perl, the sysadmin needs to do a lot of customization if they want to give a user an "rsh" level of access to Perl's capabilities.

    Spawning a new Perl for each thread really isn't the same as a per-virtual server instance of Perl. Later versions of Apache support more than one model for the association between threads and user requests. Also many Perl apps rely on the persistence of data across multiple HTTP requests - those modules can't be run in a one-interpreter-per-request environment. The only practical solution would be writing a "traffic-cop" for Perl interpreters that detected which virtual server was handling the request and returned the correct Perl interpreter for that server.

    The closest thing Perl has to "rsh"'ing a user is taint mode and some modules mentioned in the notes above this one, but neither of these really do the trick. Add-on modules aren't really a secure solution: unless you build safety features into the Perl core, it is too easy to unload a module and get back all the power of pure Perl. Taint mode isn't really designed to protect the sysadmin from the programmer. It is primarily meant to protect a skilled programmer from nasties coming from outside the program - bad user input, evil environments.

    I think this is a serious problem - with the steady advance of cloud computing, solutions that play safely in mass hosting environments are going to become increasingly important. The economic model in that space is all about volume service provision.

    However, I really dislike Byrne and Aaron's solution. It seems to me that enhancing Perl with shutoff valves and giving mod_perl better support for virtual servers would be a much smarter way to go.

    I am way too new to the open source community to have my voice heard, but I hope maybe some reading this might be seeing things the same way and be able to push those with clout on Perl and mod_perl to think a bit about this. Aaron and Byrne's solution may be short-sighted, but their vision of the problem is not.

    Best, beth

      I am way too new to the open source community to have my voice heard....

      All that matters is willingness to participate as a member of the community.

      That said, the Perl on Google App Engine project works on some of the enhancements you mention.

Re: What is mod_perlite?
by redhotpenguin (Deacon) on Jan 26, 2009 at 16:50 UTC
    When I read through this project, it reminded me of Gisle's first version of mod_perl in 1999(?). They are trying to recreate it from scratch rather than configuring mod_perl to do what they need. I'm all for hacking up cool stuff, but an hour in the library can save a few weeks in the lab.

      A big part of the solution is to provide an easy and safe apache module that admins can provide while still being able to sleep at night. If one could bundle up a pre-configured mod_perl such that it would meet those requirements, then maybe you'd have the solution that everyone is looking for.

Re: What is mod_perlite?
by belg4mit (Prior) on Jan 29, 2009 at 06:10 UTC
    I stumbled across the mod_perlite page while writing this year's advent calendar. It seemed kind of thin on details then, but potentially promising. The thing that piqued my interest was the idea of maybe twisting it into a persistent perl interpreter for running scripts from the command line.

    Update: Alas, this doesn't seem likely now.

    --
    In Bob We Trust, All Others Bring Data.

      You might find PPerl useful.

        Yes, that looks familiar too, though of slightly different design than I suggested... although I suppose one could interpose a layer that gets daemonize and whose purpose is to take the name of a script and eval it ;-D Thanks for the reminder.

        --
        In Bob We Trust, All Others Bring Data.