article about mod_perlite

I'm not sure how many of you are aware of chromatic's previous article
about "5 things perl 5 needs right now", or about the mod_perlite
project that was spawned by some people from sixapart, but chromatic has
published another article that's basically a conversation with Byrne
Reese and Aaron Stone, aka the guys at 6A that are/were working on
mod_perlite. Anyway, it might be interesting to some people on the list:

http://broadcast.oreilly.com/2009/01/cgi-is-dead-mod-perlite -is-ali.html

The project is supposed to basically be mod_perl's registry only,
packaged such that it would be possible to get mass virtual hosting
providers to install it. The core motivation being so that 6A's
Customers running MT in that architecture can get better performance.
The difference between it and FastCGI being that you can run unaltered
code originally destined for CGI, just like Registry or PerlRun.

Adam

Re: article about mod_perlite

Adam,

Thank you so much for posting this to the list. The project needs the
help of some of the Perl and Apache Module gurus I hope frequent this
list. Aaron posted the source to github, but last I heard github had
somehow managed to corrupt the source. So, Aaron should now be working
on either fixing it, or finding a new home for the project's source
code.

The current status of the project is that what we have works with
simple CGI's, but there are some many system calls (e.g. perl's die
function) that need to be given special handling, something that
mod_perl also must do as best I understand it.

I will poke and prod Aaron to chime in to give us a more detailed
explanation of the kind of help we need.

I have been following a number of conversations on the Internets about
mod_perlite, and while the initial motivation behind this module/
project was performance, I think if it is successful, the boon will
prove to be ease of installation and management of CGI scripts.

Thank you again Adam, and I will do what I can to keep this list up to
date on the project's progress. Feel free to also visit http://www.modperlite.org/

Ciao,
Byrne

On Jan 25, 2009, at 10:03 PM, Adam Prime wrote:

> I'm not sure how many of you are aware of chromatic's previous article
> about "5 things perl 5 needs right now", or about the mod_perlite
> project that was spawned by some people from sixapart, but chromatic
> has
> published another article that's basically a conversation with Byrne
> Reese and Aaron Stone, aka the guys at 6A that are/were working on
> mod_perlite. Anyway, it might be interesting to some people on the
> list:
>
> http://broadcast.oreilly.com/2009/01/cgi-is-dead-mod-perlite -is-ali.html
>
> The project is supposed to basically be mod_perl's registry only,
> packaged such that it would be possible to get mass virtual hosting
> providers to install it. The core motivation being so that 6A's
> Customers running MT in that architecture can get better performance.
> The difference between it and FastCGI being that you can run unaltered
> code originally destined for CGI, just like Registry or PerlRun.
>
> Adam

Re: article about mod_perlite

--==========D18C131FF860F21EEBAE==========
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

first thank you for mod_perlite and the background informations on it.

Some days ago we discussed in #perlde (and perhaps will continue to=20
discuss it on the German Perl Wokshop), that beside the ugly slow CGI=20
performance there is one more major problem with Perl for mainstream web=20
applications:

Bundling of applications should be easyer. So, not only the deployment of =

single CGI scripts.


For deployment we have PAR, which is great for simple deployment of big=20
applications on a lot of machines. e.g. the whole application is loadable =

via HTTP. But it is also possibe to distribute PAR archives which=20
contains everything directly.

For the user it would be really easy to build a PAR package of all his=20
Modules, Templates, ... The developer can build a .par by simply typing=20
"./Build pardist" and the user should be able to upload this directly to=20
his server. And perhaps additionally a second .par file, if he has its=20
own templates, configurations etc ... ;-)

The idea is, that mod_perlite and mod_perl can handle this with the best=20
performance available. And it should be possible to set handlers for URLs =

and more.
So, with this an end user would be able to download "MT.par", upload it=20
to his webspace and everything works out of the box.


Ciao
Alvar


--=20
** Alvar C.H. Freude, http://alvar.a-blast.org/
**=A0http://www.assoziations-blaster.de/
** http://www.wen-waehlen.de/
** http://www.perl-blog.de/

--==========D18C131FF860F21EEBAE==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkl9nn4ACgkQOndlH63J86xHwQCgtN5thBCt5mGN5FTTYNSU Hm86
61UAn2netAlQvxl4CCqe+Gi5W1rP+5+K
=zlhZ
-----END PGP SIGNATURE-----

--==========D18C131FF860F21EEBAE==========--

Re: article about mod_perlite

On Mon, Jan 26, 2009 at 1:03 AM, Adam Prime wrote:
> I'm not sure how many of you are aware of chromatic's previous article
> about "5 things perl 5 needs right now", or about the mod_perlite
> project that was spawned by some people from sixapart, but chromatic has
> published another article that's basically a conversation with Byrne
> Reese and Aaron Stone, aka the guys at 6A that are/were working on
> mod_perlite. Anyway, it might be interesting to some people on the list:
>
> http://broadcast.oreilly.com/2009/01/cgi-is-dead-mod-perlite -is-ali.html

We discussed this on PerlMonks. Here's my take on it:
http://perlmonks.org/?node_id=738192

- Perrin

Re: article about mod_perlite

Perrin Harkins wrote:
> On Mon, Jan 26, 2009 at 1:03 AM, Adam Prime wrote:
>> I'm not sure how many of you are aware of chromatic's previous article
>> about "5 things perl 5 needs right now", or about the mod_perlite
>> project that was spawned by some people from sixapart, but chromatic has
>> published another article that's basically a conversation with Byrne
>> Reese and Aaron Stone, aka the guys at 6A that are/were working on
>> mod_perlite. Anyway, it might be interesting to some people on the list:
>>
>> http://broadcast.oreilly.com/2009/01/cgi-is-dead-mod-perlite -is-ali.html
>
> We discussed this on PerlMonks. Here's my take on it:
> http://perlmonks.org/?node_id=738192
>
> - Perrin

In the context of people with uber-cheap virtual webhosting, is changing
MaxRequestsPerChild really an option? I personally have little to no
experience in that sort of setup, but that doesn't seem like something
I'd want someone to be able to screw around with.

FastCGI, to me anyway, has a big barrier to entry because you have to
modify your code to run in it. It's a pretty trivial modification mind
you, but it's a modification none the less. To people on this list it's
no big deal, but to people with $5 mass vhosting accounts that don't
know anything about anything, it is a big deal.

Fred's comment about not being able to expect much for $4.95 / month
sort of shows the disconnect between the perl and PHP worlds. for $4.95
a month one can get mass vhosting account with mysql or postgres
available, and can get WordPress installed and running without needing
to know much more than how to read, how to use and ftp client, and how
to use their unzipper of choice. In the perl world, nothing is quite
that simple. Movable Type has come pretty close, but that's only if
you're running under plain CGI (ie the devil)

Don't get me wrong, there is almost no way that i'd ever actually use
mod_perlite, but I can appreciate that there are a lot of people out
there, that might become interested in perl instead of php if this niche
was filled. For the long term health of perl 5, we would be greatly
served by bringing in more new blood.

Look at the list archive post summaries:

http://marc.info/?l=apache-modperl&r=1&w=2

Look at the results of the mod_perl survey:

http://kabob.ca/mod_perl_survey/html/

How long have you been using mod_perl?

Just started 4.2% 18
Less than one year 4.0% 17
Less than two years 8.9% 38
Less than three years 9.1% 39
Less than four years 9.6% 41
Less than five years 11.4% 49
More than five years 52.9% 227

Both of these things point out (to me anyway) that less people are
getting into mod_perl as each day goes by. mod_perlite could fill a
much needed gap between cgi on mass vhosting and mod_perl user with root
on a dedicated machine.

The other thing I think is sorely lacking is actual (easily installable)
applications, but that's another story entirely.

Adam

Re: article about mod_perlite

On Mon, Jan 26, 2009 at 1:29 PM, Adam Prime wrote:
> In the context of people with uber-cheap virtual webhosting, is changing
> MaxRequestsPerChild really an option?

No, but frankly, uber-cheap virtual hosting will never support
mod_perl or mod_perlite.

> FastCGI, to me anyway, has a big barrier to entry because you have to modify
> your code to run in it.

I don't see that as significant, and I'm sure someone could write a
Registry-style wrapper if they wanted to.

> In the perl world, nothing is quite that simple. Movable Type has come
> pretty close, but that's only if you're running under plain CGI (ie the
> devil)

Well, why doesn't Movable Type make FastCGI installation easier? A
naive question, but that sounds like the path of least resistance.
PHP stuff has to deal with a variety of deployment options too
(mod_php, FastCGI, php as CGI, code cache or not, etc).

> Don't get me wrong, there is almost no way that i'd ever actually use
> mod_perlite, but I can appreciate that there are a lot of people out there,
> that might become interested in perl instead of php if this niche was
> filled. For the long term health of perl 5, we would be greatly served by
> bringing in more new blood.

I'm happy to have people hack on their projects if they're enjoying
it, and I don't want them to stop. I do think that the best path to
widely available cheap hosting for fast perl webapps is FastCGI
though, at this point. It's already out there, and the features that
people give up by using it instead of mod_perl are not important to
this group of users.

- Perrin

Re: article about mod_perlite

Perrin Harkins schrieb:
> On Mon, Jan 26, 2009 at 1:03 AM, Adam Prime
> wrote:
>>
>> http://broadcast.oreilly.com/2009/01/cgi-is-dead-mod-perlite -is-ali.html
>
> We discussed this on PerlMonks. Here's my take on it:
> http://perlmonks.org/?node_id=738192

To quote:

| 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.

I think this is technically incorrect in that it does not match the
Apache/LibPHP execution model (which is what I think they're trying to
emulate), where the Apache/LibPHP process does not exit after serving
only a single request.

I'm not 100 % sure, but I think the Apache/LibPHP execution model
compares roughly to this:

mod_perl: Apache::PerlRun - Run unaltered CGI scripts under mod_perl
http://perl.apache.org/docs/1.0/api/Apache/PerlRun.html

PHP can leak memory, too. MaxRequestsPerChild is important, as it is
with Perl. Setting it to 1 in either case means throwing the baby out
with the bath water.

Michael Ludwig

Re: article about mod_perlite

IMO the profile below does not indicate that the sky
is falling.

A survey of "how long have you been using computers?"
might show a similar distribution.

craig
www.animalhead.com

On Jan 26, 2009, at 10:29 AM, Adam Prime wrote:

>

> How long have you been using mod_perl?
>
> Just started 4.2% 18
> Less than one year 4.0% 17
> Less than two years 8.9% 38
> Less than three years 9.1% 39
> Less than four years 9.6% 41
> Less than five years 11.4% 49
> More than five years 52.9% 227
>
> Both of these things point out (to me anyway) that less people are
> getting into mod_perl as each day goes by.

Re: article about mod_perlite

mackenna@animalhead.com wrote:
> IMO the profile below does not indicate that the sky
> is falling.
>
> A survey of "how long have you been using computers?"
> might show a similar distribution.

Just because it might have the same distribution doesn't mean it's relevant. I bet a question like
"How long have you been having sex?" would get a similar curve :) A more relevant question for
comparison would be "How long have you been using PHP?" from a PHP community survey.

While I have my doubts about mod_perlite, I think the quest to bring more new blood into the Perl
community is necessary and important one. Without it we won't get the next generation of people I'll
need to hire :)

--
Michael Peters
Plus Three, LP

Re: article about mod_perlite

On Mon, Jan 26, 2009 at 2:26 PM, Michael Ludwig wrote:
> I think this is technically incorrect in that it does not match the
> Apache/LibPHP execution model (which is what I think they're trying to
> emulate), where the Apache/LibPHP process does not exit after serving
> only a single request.

Well, is your goal to be exactly like PHP or is it to provide a fast
environment for non-persistent perl execution? Perl doesn't have the
same kind of reset switch for the interpreter, so creating a new one
each time is necessary. Setting MaxRequestsPerChild to 1 causes
apache to prefork a new process with a new interpreter for each
request. This should be faster than attempting to actually create a
new interpreter, since all it has to do is fork the parent process and
forking is very efficient on Linux and BSD.

> I'm not 100 % sure, but I think the Apache/LibPHP execution model
> compares roughly to this:
>
> mod_perl: Apache::PerlRun - Run unaltered CGI scripts under mod_perl
> http://perl.apache.org/docs/1.0/api/Apache/PerlRun.html

PerlRun is effective in many situations but it will never be as
effective as forking a fresh process/interpreter.

> PHP can leak memory, too. MaxRequestsPerChild is important, as it is
> with Perl. Setting it to 1 in either case means throwing the baby out
> with the bath water.

I disagree. In fact this was a common recommendation for use with
PerlRun in the old days when people had scripts that were just too
dirty to get running in a persistent environment.

- Perrin

Re: article about mod_perlite

Perrin Harkins schrieb:
> On Mon, Jan 26, 2009 at 2:26 PM, Michael Ludwig
> wrote:
>> I think this is technically incorrect in that it does not match the
>> Apache/LibPHP execution model (which is what I think they're trying
>> to emulate), where the Apache/LibPHP process does not exit after
>> serving only a single request.
>
> Well, is your goal to be exactly like PHP or is it to provide a fast
> environment for non-persistent perl execution? Perl doesn't have the
> same kind of reset switch for the interpreter, so creating a new one
> each time is necessary.

I may be wrong but I used to think that PerlRun provides just that, a
non-persistent execution environment, just like LibPHP. Memory consumed
by the interpreter is not deallocated in either case. (Unless, of
course, I'm wrong.)

> Setting MaxRequestsPerChild to 1 causes apache to prefork a new
> process with a new interpreter for each request. This should be
> faster than attempting to actually create a new interpreter, since
> all it has to do is fork the parent process and forking is very
> efficient on Linux and BSD.

Yes, relatively light-footed processes on these platforms. But if
forking was so efficient, why offer PerlRun?

> PerlRun is effective in many situations but it will never be as
> effective as forking a fresh process/interpreter.

That may or may not be true depending on what effect you want to
achieve. As for efficiency, I used to think that PerlRun had an edge
over forking in that respect. But well, I may be wrong.

>> PHP can leak memory, too. MaxRequestsPerChild is important, as it is
>> with Perl. Setting it to 1 in either case means throwing the baby out
>> with the bath water.
>
> I disagree. In fact this was a common recommendation for use with
> PerlRun in the old days when people had scripts that were just too
> dirty to get running in a persistent environment.

Too dirty for more than one request on PerlRun? Never seen anything as
dirty as that.

But wait, I once came upon a homegrown "framework" that implemented an
HTTP redirect by printing the header, flushing the buffer and then
calling exit(), which terminated the Apache process. That was really
dirty. The icing on the cake was that it didn't close the database
handle, and I suspected it of being the culprit for the connection
leakage we were seeing. But lacking in-depth knowledge, I never got to
the ground of it.

Note the doc for PerlRun says: "This module is meant for 'Dirty' CGI
Perl scripts [...]". Note it says "Dirty" with a capital D.

Best,

Michael Ludwig

Re: article about mod_perlite

On Mon, Jan 26, 2009 at 4:15 PM, Michael Ludwig wrote:
> I may be wrong but I used to think that PerlRun provides just that, a
> non-persistent execution environment, just like LibPHP. Memory consumed
> by the interpreter is not deallocated in either case. (Unless, of
> course, I'm wrong.)

It's not really possible in perl. PerlRun attempts to fake it by
removing anything added to the symbol table in the package it creates
for your script. However, if you load any module or use a namespace
in any way at all, you completely defeat PerlRun. For example, it
will not clear this:

$MyPackage::Count++;

Or this:
$MyCache::DBH = get_dbh();

> Yes, relatively light-footed processes on these platforms. But if
> forking was so efficient, why offer PerlRun?

Not forking is more efficient, but since the perl interpreter can't be
reset it's not as foolproof. It's a better option for people who have
relatively clean code and don't mind that modules will be persistent
but want their script's globals cleared every time.

> Too dirty for more than one request on PerlRun? Never seen anything as
> dirty as that.

If there was nothing as dirty as that, then PerlRun would be the
answer to mod_perlite. But, as I explained, PerlRun is not enough for
everyone.

> But wait, I once came upon a homegrown "framework" that implemented an
> HTTP redirect by printing the header, flushing the buffer and then
> calling exit(), which terminated the Apache process.

PerlRun and Registry usually intercept exit() calls.

> The icing on the cake was that it didn't close the database
> handle, and I suspected it of being the culprit for the connection
> leakage we were seeing.

Could be, especially since it probably didn't really exit.

- Perrin

Re: article about mod_perlite

Perrin Harkins schrieb:
> On Mon, Jan 26, 2009 at 4:15 PM, Michael Ludwig
> wrote:
>> I may be wrong but I used to think that PerlRun provides just that, a
>> non-persistent execution environment, just like LibPHP.

> It's not really possible in perl. PerlRun attempts to fake it by
> removing anything added to the symbol table in the package it creates
> for your script. However, if you load any module or use a namespace
> in any way at all, you completely defeat PerlRun. For example, it
> will not clear this:
>
> $MyPackage::Count++;
>
> Or this:
> $MyCache::DBH = get_dbh();

Okay, I see. Must admit that I've only ever used Apache::Registry and
PerlHandler, or PerlResponseHandler in 2.0.

>> Yes, relatively light-footed processes on these platforms. But if
>> forking was so efficient, why offer PerlRun?
>
> Not forking is more efficient, but since the perl interpreter can't be
> reset it's not as foolproof.

> If there was nothing as dirty as that, then PerlRun would be the
> answer to mod_perlite. But, as I explained, PerlRun is not enough for
> everyone.

Now I get it. Thanks for clarifying!

>> But wait, I once came upon a homegrown "framework" that implemented
>> an HTTP redirect by printing the header, flushing the buffer and then
>> calling exit(), which terminated the Apache process.
>
> PerlRun and Registry usually intercept exit() calls.

Don't remember whether that was exit() or CORE::exit().

>> The icing on the cake was that it didn't close the database
>> handle, and I suspected it of being the culprit for the connection
>> leakage we were seeing.
>
> Could be, especially since it probably didn't really exit.

I seem to remember adding log statements to the routine closing the
handle and seeing these triggered on server shutdown, suggesting the
process didn't really exit when exit() or CORE::exit() got called.
Certainly a very undesirable setup.

Michael Ludwig