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


in reply to What is mod_perlite?

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.

Replies are listed 'Best First'.
Re^2: What is mod_perlite?
by chromatic (Archbishop) on Jan 22, 2009 at 19:19 UTC
    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.

[reply]
      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.

[reply]
        I like the focus of the project, but I agree with what's been stated. I don't think they will add anything beneficial for Perl 5. My question is: do the internals of Perl 6 change significantly enough for a project like this to work? (Not having to reload the interpreter...keeping the web scripter's code at arm length so you have a clean container after the script has been run.) If Perl 6 can provide an environment where a mod_perl6lite would work just like mod_php, I think the web would shift back to Perl.
[reply]
      '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.

[reply]
        I don't think that the term superiority can be applied to solutions in the $4.95/month hosting market.

        How many of those hosting accounts support mod_php? How many support mod_perl or (to perrin's point), FastCGI with Perl support? Technical superiority is not the only kind of superiority.

[reply]

In Section Meditations