Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: What is mod_perlite?

by tirwhan (Abbot)
on Jan 22, 2009 at 10:11 UTC ( #738105=note: print w/replies, xml ) Need Help??


in reply to What is mod_perlite?

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.

Replies are listed 'Best First'.
Re^2: What is mod_perlite?
by jhourcle (Prior) on Jan 22, 2009 at 17:56 UTC

    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.

Re^2: What is mod_perlite?
by scorpio17 (Canon) on Jan 22, 2009 at 22:35 UTC

    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.
        It would let you put perl code into your HTML files,
        Where do you get that from?

        Well, that's the whole point. It's supposed to be dirt-simple for the web developer to use and deploy, and it doesn't get any simpler than having an html file with a little bit of perl spliced into it that gets run when you use your browser to ask to see the file. It also needs to be nearly foolproof for the average sysadmin to deploy with their apache (my understanding is that this would rule out mod_perl).

        Regarding what's compiled into or not compiled into mod_perlite, or what modules are loaded when: those are implementation issues that will probably be worked out later. Sure, it would be great if mod_perlite only reloaded modules if they've been changed. That sounds like a feature that will come later.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://738105]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2022-12-09 23:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?