Mailing List Archive: ModPerl: ModPerl

mod_perl survey results

1 2

View All

Index | Next | Previous | View Threaded

adam.prime at utoronto

Nov 9, 2008, 6:59 PM

Post #1 of 36 (1160 views)
Permalink

mod_perl survey results

The results of the mod_perl survey that Fred Moyer and I conducted can
be found at the following link:

http://kabob.ca/mod_perl_survey/

Here's a quick list of obvious (though arguable) conclusions:

- a lot of people have switched to mod_perl 2, mod_perl 1 is still very
significant.
- most of the people using mod_perl have been using it for a long time.
- the rate of new people coming into the community has been declining.
- linux is by far the most popular platform. the BSD's, Solaris and
Windows also make a significant showing.
- Fred and I didn't really break down frameworks very well, but mason,
Catalyst and CGI::Application are quite popular. TT is also very
popular, but not exactly a framework, but not quite as popular is old
fashioned Handlers.
- A surprising number of people are running mod_perl under the worker MPM.
- Most of the Handler phases are getting some use.
- There are a lot of people using CGI Emulation, which is not a surprise.
- not very many people are using the mod_perl2 filter api.
- there is quite a bit of interest in a mod_perl Workshop, but location
would be a key factor for a lot of people
- the documentation could use some work. Specifically more tutorial /
intro kind of stuff.

Adam

rs at plusw

Nov 10, 2008, 2:15 AM

Post #2 of 36 (1132 views)
Permalink

Re: mod_perl survey results [In reply to]

Hi Adam,

quite interesting.
Thanks for doing all that work.

Am Montag, 10. November 2008 03:59:13 schrieb Adam Prime:
> The results of the mod_perl survey that Fred Moyer and I conducted can
> be found at the following link:
>
> http://kabob.ca/mod_perl_survey/
>
> Here's a quick list of obvious (though arguable) conclusions:
>
> - a lot of people have switched to mod_perl 2, mod_perl 1 is still very
> significant.
> - most of the people using mod_perl have been using it for a long time.
> - the rate of new people coming into the community has been declining.
> - linux is by far the most popular platform. the BSD's, Solaris and
> Windows also make a significant showing.
> - Fred and I didn't really break down frameworks very well, but mason,
> Catalyst and CGI::Application are quite popular. TT is also very
> popular, but not exactly a framework, but not quite as popular is old
> fashioned Handlers.
> - A surprising number of people are running mod_perl under the worker MPM.
> - Most of the Handler phases are getting some use.
> - There are a lot of people using CGI Emulation, which is not a surprise.
> - not very many people are using the mod_perl2 filter api.
> - there is quite a bit of interest in a mod_perl Workshop, but location
> would be a key factor for a lot of people
> - the documentation could use some work. Specifically more tutorial /
> intro kind of stuff.
>
> Adam

--

Rolf Schaufelberger

aw at ice-sa

Nov 10, 2008, 3:46 AM

Post #3 of 36 (1134 views)
Permalink

Re: mod_perl survey results [In reply to]

Rolf Schaufelberger wrote:
> Hi Adam,
>
> quite interesting.
> Thanks for doing all that work.
Thanks too. Interesting indeed.
>
> Am Montag, 10. November 2008 03:59:13 schrieb Adam Prime:
>> The results of the mod_perl survey that Fred Moyer and I conducted can
>> be found at the following link:
>>
>> http://kabob.ca/mod_perl_survey/
>>
>> Here's a quick list of obvious (though arguable) conclusions:
>>
>> - a lot of people have switched to mod_perl 2, mod_perl 1 is still very
>> significant.
>> - most of the people using mod_perl have been using it for a long time.
>> - the rate of new people coming into the community has been declining.
The responses there are indeed a bit scary. It feels like we're a dying
breed.
I believe this is to a large extent a "marketing issue" for perl in
general, and mod_perl by extension, with regard to the younger
programmers generation. At least in various European countries I know,
perl is not really being taught in programming schools as a "serious"
programming language for applications. These young people have all heard
the name, but seem to consider it as a powerful but somewhat messy
scripting language to create system administration scripts.
I am personally doing my best to introduce these newbies to the beauties
of perl and mod_perl, but it feels rather lonely sometimes.
Java and PHP seem definitely more popular, or better-known.

>> - linux is by far the most popular platform. the BSD's, Solaris and
>> Windows also make a significant showing.
Not enough people know that Perl is at least as multi-platform as Java,
and much lighter.

>> - Fred and I didn't really break down frameworks very well, but mason,
>> Catalyst and CGI::Application are quite popular. TT is also very
>> popular, but not exactly a framework, but not quite as popular is old
>> fashioned Handlers.
>> - A surprising number of people are running mod_perl under the worker MPM.
What is so surprising about this ? (genuine curious question)

>> - Most of the Handler phases are getting some use.
>> - There are a lot of people using CGI Emulation, which is not a surprise.
>> - not very many people are using the mod_perl2 filter api.
>> - there is quite a bit of interest in a mod_perl Workshop, but location
>> would be a key factor for a lot of people
>> - the documentation could use some work. Specifically more tutorial /
>> intro kind of stuff.
Agreed. There is a definite need also for something like a new mod_perl
Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section
about the framework/template systems mentioned above. Written in a style
meant to show that these are not old-fashioned technologies only
practised by oldies like me (us?).
What I mean is that to cover all one needs to know to create some
serious web applications in Java, you'd need at least 6 thick volumes,
while for Perl 800-1000 pages would be more than enough.
O'Reilly, where are you ?

Stas Beckman's mod_perl 2 book is good, but I believe only really
accessible to people who already know perl and mod_perl quite well.
The CPAN library is incredibly rich, and the documentation of most
modules is a superb source of information on a lot of things, even apart
from the pure perl aspect of it. But the main issue I believe is that
younger programmers don't even go looking there, because they are
intimidated by perl. It's a pity.

Maybe there isn't much to do about it though, except feeling nostalgia.
Both Java and PHP have a few commercial organisations behind them to
promote them, while Perl doesn't really. Maybe that's the difference in
the long term.

I work for a small company, and we know that using perl and mod_perl and
CPAN and Apache, we can do things that would be out of our reach
otherwise. So we know we're on to a good thing for ourselves, but it is
not really enough to make these things more popular on a broad scale.

adam.prime at utoronto

Nov 10, 2008, 5:59 AM

Post #4 of 36 (1124 views)
Permalink

Re: mod_perl survey results [In reply to]

Andr� Warnier wrote:
> The responses there are indeed a bit scary. It feels like we're a dying
> breed.
> I believe this is to a large extent a "marketing issue" for perl in
> general, and mod_perl by extension, with regard to the younger
> programmers generation. At least in various European countries I know,
> perl is not really being taught in programming schools as a "serious"
> programming language for applications. These young people have all heard
> the name, but seem to consider it as a powerful but somewhat messy
> scripting language to create system administration scripts.
> I am personally doing my best to introduce these newbies to the beauties
> of perl and mod_perl, but it feels rather lonely sometimes.
> Java and PHP seem definitely more popular, or better-known.

I agree that this does echo perl's problems in general, but mod_perl has
a long history of not really being very good at marketing itself. I
know Perrin and some other people did try at the launch of mod_perl2,
but that effort (and the associated mailing list) has long since dried up.

> - A surprising number of people are running mod_perl under the worker
> MPM.
> What is so surprising about this ? (genuine curious question)

It's surprising to me, and probably to Torsten, because the perceived
common wisdom is to run prefork, because worker may or may not be as
well tested, and has all the bonus issues related to thread-safeness.

>>> - the documentation could use some work. Specifically more tutorial /
>>> intro kind of stuff.
> Agreed. There is a definite need also for something like a new mod_perl
> Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section
> about the framework/template systems mentioned above. Written in a style
> meant to show that these are not old-fashioned technologies only
> practised by oldies like me (us?).
> What I mean is that to cover all one needs to know to create some
> serious web applications in Java, you'd need at least 6 thick volumes,
> while for Perl 800-1000 pages would be more than enough.
> O'Reilly, where are you ?

Honestly, I think this stuff is currently better handled by the
community. As such, i'm going to take a stab at writing some very basic
intro / tutorial kind of documentation to be added to perl.apache.org.
When i started with mod_perl 1, the Guide on thought the "guide"
perl.apache.org was amazing, but it seems to me that mod_perl 2 doesn't
have that in the same way. Much of the content has been ported over to
the 2.0 section, but there are many pages that haven't been updated from
the 1.0 tree at all.

Adam

smsiebe at gmail

Nov 10, 2008, 6:38 AM

Post #5 of 36 (1123 views)
Permalink

Re: mod_perl survey results [In reply to]

I'm relatively new to mod_perl - moving to a new job who's application
is solely written in it. This is a return to Perl for me, having
worked in PHP, Java, and .NET since Perl 4. As I'm learning to love
mod_perl and Perl in general, perhaps it's a good time for me to
contribute back by writing perl/mod_perl blogs and tutorials to help
others easing in from other languages (written with a set of
assumptions). I've seen the "to-do" list, if you will, on the
mod_perl Advocacy page
(http://perl.apache.org/docs/general/advocacy/advocacy.html) but not
sure how dated this is or what is the best to tackle.

Let me know how to get involved - it is my job security after all =).
Seriously, though, the flexibility of mod_perl is just not available
in many of the other languages and I think it's "don't know what you
don't know" sort of thing...so much work is done in the application
code when it could be solved with a few lines using mod_perl at the
httpd abstract layer. I have a blog site but if perl.apache.org
desires host tutorials and blogs, so much the better (better
discoverability).

I've also noticed the mod_perl advocacy mailing list is all but dead.
Perhaps this is the best channel to bring these issues up?

Regards,

Steve

On Mon, Nov 10, 2008 at 8:59 AM, Adam Prime <adam.prime[at]utoronto.ca> wrote:
> Andr� Warnier wrote:
>>
>> The responses there are indeed a bit scary. It feels like we're a dying
>> breed.
>> I believe this is to a large extent a "marketing issue" for perl in
>> general, and mod_perl by extension, with regard to the younger programmers
>> generation. At least in various European countries I know, perl is not
>> really being taught in programming schools as a "serious" programming
>> language for applications. These young people have all heard the name, but
>> seem to consider it as a powerful but somewhat messy scripting language to
>> create system administration scripts.
>> I am personally doing my best to introduce these newbies to the beauties
>> of perl and mod_perl, but it feels rather lonely sometimes.
>> Java and PHP seem definitely more popular, or better-known.
>
> I agree that this does echo perl's problems in general, but mod_perl has a
> long history of not really being very good at marketing itself. I know
> Perrin and some other people did try at the launch of mod_perl2, but that
> effort (and the associated mailing list) has long since dried up.
>
>> - A surprising number of people are running mod_perl under the worker MPM.
>> What is so surprising about this ? (genuine curious question)
>
> It's surprising to me, and probably to Torsten, because the perceived common
> wisdom is to run prefork, because worker may or may not be as well tested,
> and has all the bonus issues related to thread-safeness.
>
>>>> - the documentation could use some work. Specifically more tutorial /
>>>> intro kind of stuff.
>>
>> Agreed. There is a definite need also for something like a new mod_perl
>> Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section
>> about the framework/template systems mentioned above. Written in a style
>> meant to show that these are not old-fashioned technologies only practised
>> by oldies like me (us?).
>> What I mean is that to cover all one needs to know to create some serious
>> web applications in Java, you'd need at least 6 thick volumes, while for
>> Perl 800-1000 pages would be more than enough.
>> O'Reilly, where are you ?
>
> Honestly, I think this stuff is currently better handled by the community.
> As such, i'm going to take a stab at writing some very basic intro /
> tutorial kind of documentation to be added to perl.apache.org. When i
> started with mod_perl 1, the Guide on thought the "guide" perl.apache.org
> was amazing, but it seems to me that mod_perl 2 doesn't have that in the
> same way. Much of the content has been ported over to the 2.0 section, but
> there are many pages that haven't been updated from the 1.0 tree at all.
>
> Adam
>

adam.prime at utoronto

Nov 10, 2008, 7:10 AM

Post #6 of 36 (1127 views)
Permalink

Re: mod_perl survey results [In reply to]

Steven Siebert wrote:
> I'm relatively new to mod_perl - moving to a new job who's application
> is solely written in it. This is a return to Perl for me, having
> worked in PHP, Java, and .NET since Perl 4. As I'm learning to love
> mod_perl and Perl in general, perhaps it's a good time for me to
> contribute back by writing perl/mod_perl blogs and tutorials to help
> others easing in from other languages (written with a set of
> assumptions). I've seen the "to-do" list, if you will, on the
> mod_perl Advocacy page
> (http://perl.apache.org/docs/general/advocacy/advocacy.html) but not
> sure how dated this is or what is the best to tackle.
>
That page probably dates back to late 2004, which is when mod_perl 2
actually hit the streets, and the last time the advocacy mailing list
saw any sort of usage. The mp-advocacy archives can been seen here:
http://marc.info/?l=apache-modperl-advocacy&r=1&w=2, and is, as you
noticed, pretty much dead. I'm not in any way the boss of this sort of
stuff, but i'd say if you want to bring anything up, you should
probably bring it up here. If, by some miracle advocacy talk (and even
better work), starts getting too chattery on this list, then it could be
moved.

I think people blogging about mod_perl would be great, but personally, I
think that the best place for tutorials is ultimately on perl.apache.org.

> Let me know how to get involved - it is my job security after all =).
> Seriously, though, the flexibility of mod_perl is just not available
> in many of the other languages and I think it's "don't know what you
> don't know" sort of thing...so much work is done in the application
> code when it could be solved with a few lines using mod_perl at the
> httpd abstract layer. I have a blog site but if perl.apache.org
> desires host tutorials and blogs, so much the better (better
> discoverability).
>
http://perl.apache.org/contribute/ has some pointers about different
ways you can help, but this page too probably hasn't been updated in
years. I think you're absolutely right about the "don't know what you
don't know thing". If more people we're blogging about problems they'd
defeated with mod_perl it couldn't hurt the situation, at least IMO. I
believe that most, if not all, of perl.apache.org is built out of the
/modperl-docs/ SVN repository.

Adam

aw at ice-sa

Nov 10, 2008, 7:39 AM

Post #7 of 36 (1125 views)
Permalink

Re: mod_perl survey results [In reply to]

Ok guys, I'm nowhere as good a programmer as many people on this list,
but a) I do have patience with beginners, b) I'm convinced and c) maybe
I can do something in terms of documentation, if only to fix missing
links. And d) I'd love to see my name somewhere as a contributor, even
at the very end and in small font.
So, where do I start ?

Steven Siebert wrote:
> I'm relatively new to mod_perl - moving to a new job who's application
> is solely written in it. This is a return to Perl for me, having
> worked in PHP, Java, and .NET since Perl 4. As I'm learning to love
> mod_perl and Perl in general, perhaps it's a good time for me to
> contribute back by writing perl/mod_perl blogs and tutorials to help
> others easing in from other languages (written with a set of
> assumptions). I've seen the "to-do" list, if you will, on the
> mod_perl Advocacy page
> (http://perl.apache.org/docs/general/advocacy/advocacy.html) but not
> sure how dated this is or what is the best to tackle.
>
> Let me know how to get involved - it is my job security after all =).
> Seriously, though, the flexibility of mod_perl is just not available
> in many of the other languages and I think it's "don't know what you
> don't know" sort of thing...so much work is done in the application
> code when it could be solved with a few lines using mod_perl at the
> httpd abstract layer. I have a blog site but if perl.apache.org
> desires host tutorials and blogs, so much the better (better
> discoverability).
>
> I've also noticed the mod_perl advocacy mailing list is all but dead.
> Perhaps this is the best channel to bring these issues up?
>
> Regards,
>
> Steve
>
> On Mon, Nov 10, 2008 at 8:59 AM, Adam Prime <adam.prime[at]utoronto.ca> wrote:
>> Andr� Warnier wrote:
>>> The responses there are indeed a bit scary. It feels like we're a dying
>>> breed.
>>> I believe this is to a large extent a "marketing issue" for perl in
>>> general, and mod_perl by extension, with regard to the younger programmers
>>> generation. At least in various European countries I know, perl is not
>>> really being taught in programming schools as a "serious" programming
>>> language for applications. These young people have all heard the name, but
>>> seem to consider it as a powerful but somewhat messy scripting language to
>>> create system administration scripts.
>>> I am personally doing my best to introduce these newbies to the beauties
>>> of perl and mod_perl, but it feels rather lonely sometimes.
>>> Java and PHP seem definitely more popular, or better-known.
>> I agree that this does echo perl's problems in general, but mod_perl has a
>> long history of not really being very good at marketing itself. I know
>> Perrin and some other people did try at the launch of mod_perl2, but that
>> effort (and the associated mailing list) has long since dried up.
>>
>>> - A surprising number of people are running mod_perl under the worker MPM.
>>> What is so surprising about this ? (genuine curious question)
>> It's surprising to me, and probably to Torsten, because the perceived common
>> wisdom is to run prefork, because worker may or may not be as well tested,
>> and has all the bonus issues related to thread-safeness.
>>
>>>>> - the documentation could use some work. Specifically more tutorial /
>>>>> intro kind of stuff.
>>> Agreed. There is a definite need also for something like a new mod_perl
>>> Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section
>>> about the framework/template systems mentioned above. Written in a style
>>> meant to show that these are not old-fashioned technologies only practised
>>> by oldies like me (us?).
>>> What I mean is that to cover all one needs to know to create some serious
>>> web applications in Java, you'd need at least 6 thick volumes, while for
>>> Perl 800-1000 pages would be more than enough.
>>> O'Reilly, where are you ?
>> Honestly, I think this stuff is currently better handled by the community.
>> As such, i'm going to take a stab at writing some very basic intro /
>> tutorial kind of documentation to be added to perl.apache.org. When i
>> started with mod_perl 1, the Guide on thought the "guide" perl.apache.org
>> was amazing, but it seems to me that mod_perl 2 doesn't have that in the
>> same way. Much of the content has been ported over to the 2.0 section, but
>> there are many pages that haven't been updated from the 1.0 tree at all.
>>
>> Adam
>>
>

perrin at elem

Nov 10, 2008, 8:16 AM

Post #8 of 36 (1122 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon, Nov 10, 2008 at 6:46 AM, Andr� Warnier <aw[at]ice-sa.com> wrote:
>>> - A surprising number of people are running mod_perl under the worker
>>> MPM.
>
> What is so surprising about this ? (genuine curious question)

Because of the way perl threads use memory, you end up using less a
lot less memory with prefork than with threads on Linux/BSD. This has
been discussed on the mailing list many times. The only platform
where I expect to see people use threads is Windows, since they have
no choice there.

- Perrin

aw at ice-sa

Nov 10, 2008, 8:25 AM

Post #9 of 36 (1123 views)
Permalink

Re: mod_perl survey results [In reply to]

Perrin Harkins wrote:
> On Mon, Nov 10, 2008 at 6:46 AM, Andr� Warnier <aw[at]ice-sa.com> wrote:
>>>> - A surprising number of people are running mod_perl under the worker
>>>> MPM.
>> What is so surprising about this ? (genuine curious question)
>
> Because of the way perl threads use memory, you end up using less a
> lot less memory with prefork than with threads on Linux/BSD. This has
> been discussed on the mailing list many times. The only platform
> where I expect to see people use threads is Windows, since they have
> no choice there.
>
> - Perrin
>
Maybe this is the time to ask.
I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from
there (apt-get).
I have never been quite sure which mpm the packager decided to
configure, as the apache2.conf contains parameters for prefork, pthread
and perchild. So,
a) which is the best way to find out ?
b) if it happened to be "worker" or something, could I just change that
to "prefork", or is there more to it ?

(Also so far, even if it is using a threaded mpm, it does not seem to
have any deleterious effect on my systems, which are pretty stable).

Thanks

smsiebe at gmail

Nov 10, 2008, 8:28 AM

Post #10 of 36 (1126 views)
Permalink

Re: mod_perl survey results [In reply to]

More memory but potentially faster, correct? Since we don't have to
spawn as many processes to accommodate a load? Although i don't use
worker MPM since the codebase I adopted is not thread safe, I would
investigate if it was an option. Memory is fairly cheap and, with my
web servers (without DB's on it - just web servers) with 32 gigs of
RAM.....speed is more important.

Plus, of course, "threads" ge "optimization silver bullet"....right? =)

On Mon, Nov 10, 2008 at 11:16 AM, Perrin Harkins <perrin[at]elem.com> wrote:
> On Mon, Nov 10, 2008 at 6:46 AM, Andr� Warnier <aw[at]ice-sa.com> wrote:
>>>> - A surprising number of people are running mod_perl under the worker
>>>> MPM.
>>
>> What is so surprising about this ? (genuine curious question)
>
> Because of the way perl threads use memory, you end up using less a
> lot less memory with prefork than with threads on Linux/BSD. This has
> been discussed on the mailing list many times. The only platform
> where I expect to see people use threads is Windows, since they have
> no choice there.
>
> - Perrin
>

perrin at elem

Nov 10, 2008, 8:38 AM

Post #11 of 36 (1123 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon, Nov 10, 2008 at 11:28 AM, Steven Siebert <smsiebe[at]gmail.com> wrote:
> More memory but potentially faster, correct? Since we don't have to
> spawn as many processes to accommodate a load?

No, there's no speed advantage to threads. In fact perl is measurably
faster if you compile it with no thread support.

> Memory is fairly cheap and, with my
> web servers (without DB's on it - just web servers) with 32 gigs of
> RAM.....speed is more important.

Memory isn't cheap enough to ignore. It limits the number of backends
you can run and the amount of caching you can do. Being careful with
memory will get a lot more scalability out of your hardware.

- Perrin

adam.prime at utoronto

Nov 10, 2008, 8:47 AM

Post #12 of 36 (1122 views)
Permalink

Re: mod_perl survey results [In reply to]

Andr� Warnier wrote:
> Maybe this is the time to ask.
> I am using Linux Debian, and getting Apache 2, perl and mod_perl 2
> from there (apt-get).
> I have never been quite sure which mpm the packager decided to
> configure, as the apache2.conf contains parameters for prefork,
> pthread and perchild. So,
> a) which is the best way to find out ?
> b) if it happened to be "worker" or something, could I just change
> that to "prefork", or is there more to it ?
>
> (Also so far, even if it is using a threaded mpm, it does not seem to
> have any deleterious effect on my systems, which are pretty stable).
>
> Thanks
./httpd -V
Server version: Apache/2.0.54
Server built: Sep 25 2005 00:31:31
Server's Module Magic Number: 20020903:9
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
...

The -D APACHE_MPM_DIR tells you which MPM your apache is using. In
order to change MPM's you need to recompile apache, and quite possibly
mod_perl as well, i have no idea how you'd accomplish that on debian
using apt.

torsten.foertsch at gmx

Nov 10, 2008, 8:59 AM

Post #13 of 36 (1128 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon 10 Nov 2008, Steven Siebert wrote:
> Let me know how to get involved

How well is your C? There is a segfault waiting to be hunted down. It's
one of the nicer. It happens each time the test suite runs with worker
MPM. If interested I can give you further information.

The threading branch at
http://svn.apache.org/repos/asf/perl/modperl/branches/threading needs a
few ifdefs to work with perls without threading support. That branch is
also a good starting point for the segfault above.

Try out the threading branch with the Windows MPM. I don't have Windows
(and don't care much). So there may be a lot to do.

Further on the line I have a few ideas how to make modperl consume less
memory when running under a threaded MPM.

I think we really need better threading support to survive. We can of
course repeat the mantra "use prefork" ever again. But many apache
developers tend to use a threaded MPM as default. Some days ago Paul
Querna even asked how valuable copy-on-write is and if it can be
dropped in favor of better Windows compatibility. The day will come
when prefork is not the default MPM even on Unix-like systems.

Of course there is always a need for advocacy, writing papers,
presentations, case studies, cool solutions etc.

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch[at]gmx.net

torsten.foertsch at gmx

Nov 10, 2008, 9:00 AM

Post #14 of 36 (1123 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon 10 Nov 2008, Andr� Warnier wrote:
> Ok guys, I'm nowhere as good a programmer as many people on this
> list, but a) I do have patience with beginners, b) I'm convinced and
> c) maybe I can do something in terms of documentation, if only to fix
> missing links. And d) I'd love to see my name somewhere as a
> contributor, even at the very end and in small font.
> So, where do I start ?

c) See http://perl.apache.org/contribute/index.html. Lately there have
been a few complains about missing, incomplete or misleading docs on
the list. You could start to submit patches. A simple one could be
this: http://www.gossamer-threads.com/lists/modperl/dev/98380. Find out
why it was that way in the first place then patch it.

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch[at]gmx.net

aw at ice-sa

Nov 10, 2008, 9:28 AM

Post #15 of 36 (1121 views)
Permalink

Re: mod_perl survey results [In reply to]

Adam Prime wrote:
> Andr� Warnier wrote:
>> Maybe this is the time to ask.
>> I am using Linux Debian, and getting Apache 2, perl and mod_perl 2
>> from there (apt-get).
>> I have never been quite sure which mpm the packager decided to
>> configure, as the apache2.conf contains parameters for prefork,
>> pthread and perchild. So,
>> a) which is the best way to find out ?
>> b) if it happened to be "worker" or something, could I just change
>> that to "prefork", or is there more to it ?
>>
>> (Also so far, even if it is using a threaded mpm, it does not seem to
>> have any deleterious effect on my systems, which are pretty stable).
>>
>> Thanks
> ./httpd -V
> Server version: Apache/2.0.54
> Server built: Sep 25 2005 00:31:31
> Server's Module Magic Number: 20020903:9
> Architecture: 32-bit
> Server compiled with....
> -D APACHE_MPM_DIR="server/mpm/prefork"
> ...
>
> The -D APACHE_MPM_DIR tells you which MPM your apache is using. In
> order to change MPM's you need to recompile apache, and quite possibly
> mod_perl as well, i have no idea how you'd accomplish that on debian
> using apt.
>
>

Thanks.

In case anybody is interested, here it is thus under Debian Etch :
uname -a :
Linux arthur 2.6.18-6-686 #1 SMP Thu May 8 07:34:27 UTC 2008 i686 GNU/Linux
root[at]arthur:~# /usr/sbin/apache2ctl -V
Server version: Apache/2.2.3
Server built: Jan 27 2008 18:13:21
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
root[at]arthur:~#

prefork thus.
I'll re-read the previous posts now, about what's better, faster,
sexier, etc..

Andr�

perrin at elem

Nov 10, 2008, 9:29 AM

Post #16 of 36 (1126 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon, Nov 10, 2008 at 11:45 AM, Issac Goldstand <mmsuccess08[at]gmail.com> wrote:
> However, it's not necessarily better if your memory consumption goes
> mostly to run-time data which can't be pre-generated (in which case
> worker is better for the reasons listed below, since there's no COW benefit)

That's true if you're talking about data that you load into an
explicitly shared variable, but I have to say I have never seen that
scenario in real life. For almost everyone, the memory used by
lexical variables and code is the vast majority.

Every now and then someone comes along claiming that databases are too
slow for them and wanting to share a massive structure between apache
children. Those people should try threads (and probably compare to
prefork + BerkeleyDB).

> The reason that so many people like worker, I think, is because mp2 was
> designed so you can have workers shift from thread to thread, and be
> able to serve both mp and static content from the same Apache without
> losing performance, since not every child needs it's own "private"
> interpreter. This out-performs preform in almost every way... except
> memory sharing.

Well, I'd say it outperforms prefork in one way, which is that you
don't need a front-end proxy server and thus avoid that overhead. It
would be great to see some benchmark numbers on this. Unfortunately,
that gain is pretty much swamped by the reduced number of back-ends
you can run with threads due to the additional memory required.

- Perrin

torsten.foertsch at gmx

Nov 10, 2008, 9:37 AM

Post #17 of 36 (1125 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon 10 Nov 2008, Steven Siebert wrote:
> More memory but potentially faster, correct? �Since we don't have to
> spawn as many processes to accommodate a load?

Perl is a real memory hog. Byte-compiled code can become quite big.
Multiply that with the number of perl interpreters running and you'll
get huge numbers. With the prefork MPM we use the "load all modules you
need at startup" mantra. This way the operating system comes to rescue
with copy-on-write. The byte-compiled code is almost read-only after it
is compiled. If it is compiled by the perl interpreter in the parent
apache all that memory becomes shared memory.

With a threaded MPM the situation is different. Here at startup we have
one perl interpreter that loads all the modules. Then AFTER the child
is forked it creates as many as configured additional interpreters.
Each of those is a copy of the master interpreter. But now all the
memory that holds the byte-compiled code is allocated again for each
interpreter and almost nothing is shared by copy-on-write. So the
creation of a new perl interpreter is really expensive.

Although there is one sane usage of modperl with a threaded MPM, I
believe. If your only modperl usage is to configure the request at
runtime, do authentication etc you need the interpreter only for a
small part of the request cycle. So you can configure say 3
interpreters to handle 250 or so threads. But for that to become usable
we need a better modperl and perhaps better MPMs (event based).

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch[at]gmx.net

john at mmmi

Nov 10, 2008, 11:04 AM

Post #18 of 36 (1122 views)
Permalink

Re: mod_perl survey results [In reply to]

On Mon, 10 Nov 2008, Adam Prime wrote:

> Andr� Warnier wrote:
>> Maybe this is the time to ask.
>> I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from
>> there (apt-get).
>> I have never been quite sure which mpm the packager decided to configure,
>> as the apache2.conf contains parameters for prefork, pthread and perchild.
>
> ./httpd -V
> Server version: Apache/2.0.54
> Server built: Sep 25 2005 00:31:31
> Server's Module Magic Number: 20020903:9
> Architecture: 32-bit
> Server compiled with....
> -D APACHE_MPM_DIR="server/mpm/prefork"
> ...
>
> The -D APACHE_MPM_DIR tells you which MPM your apache is using. In order to
> change MPM's you need to recompile apache, and quite possibly mod_perl as
> well, i have no idea how you'd accomplish that on debian using apt.

The Debian distribution packages the different MPMs into different
binary packages, which are labelled as alternatives to each other, so you
load apache2-common and the MPM of your choice. Each MPM package contains
a suitably compiled binary. If you don't choose explicitly, apt-get picks
one (prefork, I think) for you.

However, and it's an important one, the Debian packaging system
also contains expectations from the maintainer(s) about which MPMs are
required or recommended for mod_perl2, mod_php5, and so forth, and will
not let you choose an MPM which those extra packages do not allow. If you
want a free choice of configuration, e.g. to run mod_perl2 threaded, you
may have to rebuild the packages yourself or build from source.

Cheers,

John

jhfoo-ml at extracktor

Nov 10, 2008, 10:50 PM

Post #19 of 36 (1085 views)
Permalink

Re: mod_perl survey results [In reply to]

Adam Prime wrote:
> The results of the mod_perl survey that Fred Moyer and I conducted can
> be found at the following link:
Interesting list. Any chance the workshop will come to Singapore? :)

I am strangely excited by the potential of filters. mod_perl feels like
a generic tool that can do more than just apps (as evidenced by the fact
that not PerlResponseHandler is only used by 68.8% of apps). Yet after
all these years I'm still not scratching beyond the surface of its
capabilities.

But then again, I'm but a dying breed in my country...

david at kineticode

Nov 11, 2008, 9:49 AM

Post #20 of 36 (1086 views)
Permalink

Re: mod_perl survey results [In reply to]

On Nov 10, 2008, at 3:46 AM, Andr� Warnier wrote:

>>> - the rate of new people coming into the community has been
>>> declining.
>
> The responses there are indeed a bit scary. It feels like we're a
> dying breed.
> I believe this is to a large extent a "marketing issue" for perl in
> general, and mod_perl by extension, with regard to the younger
> programmers generation. At least in various European countries I
> know, perl is not really being taught in programming schools as a
> "serious" programming language for applications. These young people
> have all heard the name, but seem to consider it as a powerful but
> somewhat messy scripting language to create system administration
> scripts.

Frankly, I think that a lot of people thing that Apache/mod_perl is
much too big and complex. They tend to prefer small single-process
servers, like mongrel, running on lots of ports. FastCGI has many
fans, as well. Even AxKit ships with its own fast and light Web
server. For adherents of the fast and light server (handle HTTP and
get out of my way!), Apache/mod_perl just seems like overkill.

To a certain degree, Apache/mod_perl is a victim of the success of
HTTP. It's fairly easy to implement a new HTTP server, so there are a
lot of them, and many are easy to use and extremely fast. If all
you're interested in is serving a Rails or Catalyst app, Apache/
mod_perl starts to seem like much too big a beast.

Personally, I'm still a fan. But there are a lot of other attractive
options out there, and, as has been pointed out elsewhere in this
thread, folks who like and use mod_perl seem more interested in
getting their jobs done than in evangelizing or marketing. Can't say I
blame them.

Best,

David

perrin at elem

Nov 11, 2008, 10:15 AM

Post #21 of 36 (1083 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler <david[at]kineticode.com> wrote:
> To a certain degree, Apache/mod_perl is a victim of the success of HTTP.
> It's fairly easy to implement a new HTTP server, so there are a lot of them,
> and many are easy to use and extremely fast. If all you're interested in is
> serving a Rails or Catalyst app, Apache/mod_perl starts to seem like much
> too big a beast.

I've said this before, but I think this is not a very rational claim.
Network servers are actually pretty hard to get right and HTTP is no
longer very simple. More to the point, there's nothing "heavy" about
apache/mod_perl compared to other web servers + FastCGI. An
event-based server like Lighttpd will have better performance than
Apache 2's worker MPM (the recommended choice for front-end proxies)
on static files, but who has a bottleneck on static files these days?

I'm fine with people using other open source tools to get where they
want to go but the justifications they make about mod_perl being
heavier or slower rarely have any actual research behind them.

Hmm, this is making me want to run benchmarks! Maybe a solid set of
benchmarks would be a fun OSCON presentation next year.

- Perrin

mpeters at plusthree

Nov 11, 2008, 10:19 AM

Post #22 of 36 (1084 views)
Permalink

Re: mod_perl survey results [In reply to]

> Hmm, this is making me want to run benchmarks! Maybe a solid set of
> benchmarks would be a fun OSCON presentation next year.

++

I've loved your other comparison talks in the past and this would be a nice one. Make sure to
include the new Mojo (kind of like Mongrel but in Perl).

--
Michael Peters
Plus Three, LP

david at kineticode

Nov 11, 2008, 10:27 AM

Post #23 of 36 (1085 views)
Permalink

Re: mod_perl survey results [In reply to]

On Nov 11, 2008, at 10:15 AM, Perrin Harkins wrote:

> I'm fine with people using other open source tools to get where they
> want to go but the justifications they make about mod_perl being
> heavier or slower rarely have any actual research behind them.

Yeah, I wasn't making the case for mongrel or lighthttpd myself. I
still prefer mod_perl. But that argument is out there.

> Hmm, this is making me want to run benchmarks! Maybe a solid set of
> benchmarks would be a fun OSCON presentation next year.

Great idea.

Best,

David

siracusa at gmail

Nov 11, 2008, 10:41 AM

Post #24 of 36 (1091 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 1:15 PM, Perrin Harkins <perrin[at]elem.com> wrote:
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler <david[at]kineticode.com> wrote:
>> To a certain degree, Apache/mod_perl is a victim of the success of HTTP. It's
>> fairly easy to implement a new HTTP server, so there are a lot of them, and
>> many are easy to use and extremely fast. If all you're interested in is
>> serving a Rails or Catalyst app, Apache/mod_perl starts to seem like much too
>> big a beast.
>>
> I've said this before, but I think this is not a very rational claim. Network
> servers are actually pretty hard to get right and HTTP is no longer very
> simple.

Exactly. Anyone trying to make their own HTTP server will simply end
up re-treading the same path that apache has already traveled--with
all the pitfalls that entails. HTTP serving, process management, etc.
is not the core function of most apps. The "OSS way" is to build on
the work of others.

Apache is and has been "solving the HTTP/server problem" for many
years. Choosing not to stand on the shoulders of that giant should be
done only with a very good reason. And sometimes there are good
reasons. But what I tend to see just as often are fads and other herd
behavior (e.g., the long (ongoing) trail of HTTP server/interfaces
used with Rails).

-John

fred at redhotpenguin

Nov 11, 2008, 10:48 AM

Post #25 of 36 (1089 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 10:15 AM, Perrin Harkins <perrin[at]elem.com> wrote:
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler <david[at]kineticode.com> wrote:
> I've said this before, but I think this is not a very rational claim.
> Network servers are actually pretty hard to get right and HTTP is no
> longer very simple. More to the point, there's nothing "heavy" about
> apache/mod_perl compared to other web servers + FastCGI. An
> event-based server like Lighttpd will have better performance than
> Apache 2's worker MPM (the recommended choice for front-end proxies)
> on static files, but who has a bottleneck on static files these days?

At ApacheCon, the subject of Lighttpd came up in comparison to Apache.
Paul Querna remarked that Apache and Lighttpd are about the same
speed since they have basically the same system calls. Lighttpd slows
down though when you have to stop it and apply security patches; count
the number of times you find the word attacker and vulnerability on
the patches linked to this page - http://www.lighttpd.net/download

Another good counter argument to those who say they would rather use
something instead of Apache/mod_perl is "Have you tried it server X
instead of Apache/mod_perl?". Then count the number of crickets you
hear chirping; a good number of people who have told me they would
rather use server X haven't taken the time to set it up and try it
out. After all, FastCGI must be Fast, right? :)

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com