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.
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?
?? . I don't see where even theoretically mod_perlite would offer something that FastCGI doesn't.
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?
In reply to Re: What is mod_perlite?
by tirwhan
in thread What is mod_perlite?
by Scott7477
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |