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

Re: mod_perl survey results

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

Re: mod_perl survey results

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.

Re: mod_perl survey results

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

Re: mod_perl survey results

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 =3D).
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 wrote:
> Andr=E9 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 programme=
rs
>> 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, b=
ut
>> 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 MP=
M.
>> What is so surprising about this ? (genuine curious question)
>
> It's surprising to me, and probably to Torsten, because the perceived com=
mon
> 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 practis=
ed
>> by oldies like me (us?).
>> What I mean is that to cover all one needs to know to create some seriou=
s
>> 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, b=
ut
> there are many pages that haven't been updated from the 1.0 tree at all.
>
> Adam
>

Re: mod_perl survey results

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

Re: mod_perl survey results

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

Re: mod_perl survey results

On Mon, Nov 10, 2008 at 6:46 AM, Andr=E9 Warnier 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

Re: mod_perl survey results

Perrin Harkins wrote:
> On Mon, Nov 10, 2008 at 6:46 AM, André Warnier 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

Re: mod_perl survey results

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? =3D)


On Mon, Nov 10, 2008 at 11:16 AM, Perrin Harkins wrote:
> On Mon, Nov 10, 2008 at 6:46 AM, Andr=E9 Warnier 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
>

Re: mod_perl survey results

On Mon, Nov 10, 2008 at 11:28 AM, Steven Siebert 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

Re: mod_perl survey results

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.

Re: mod_perl survey results

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/thread ing 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@gmx.net

Re: mod_perl survey results

On Mon 10 Nov 2008, Andr=E9 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=20
been a few complains about missing, incomplete or misleading docs on=20
the list. You could start to submit patches. A simple one could be=20
this: http://www.gossamer-threads.com/lists/modperl/dev/98380. Find out=20
why it was that way in the first place then patch it.

Torsten

=2D-
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net

Re: mod_perl survey results

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@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@arthur:~#

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


André

Re: mod_perl survey results

On Mon, Nov 10, 2008 at 11:45 AM, Issac Goldstand 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

Re: mod_perl survey results

On Mon 10 Nov 2008, Steven Siebert wrote:
> More memory but potentially faster, correct? =A0Since 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.=20
Multiply that with the number of perl interpreters running and you'll=20
get huge numbers. With the prefork MPM we use the "load all modules you=20
need at startup" mantra. This way the operating system comes to rescue=20
with copy-on-write. The byte-compiled code is almost read-only after it=20
is compiled. If it is compiled by the perl interpreter in the parent=20
apache all that memory becomes shared memory.

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

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

Torsten

=2D-
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net

Re: mod_perl survey results

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---1073082115-1139661777-1226343843=:30404
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID:


On Mon, 10 Nov 2008, Adam Prime wrote:

> Andr=E9 Warnier wrote:
>> Maybe this is the time to ask.
>> I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from=
=20
>> there (apt-get).
>> I have never been quite sure which mpm the packager decided to configure=
,=20
>> as the apache2.conf contains parameters for prefork, pthread and perchil=
d.=20
>
> ./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=3D"server/mpm/prefork"
> ...
>
> The -D APACHE_MPM_DIR tells you which MPM your apache is using. In order=
to=20
> change MPM's you need to recompile apache, and quite possibly mod_perl as=
=20
> well, i have no idea how you'd accomplish that on debian using apt.

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

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

Cheers,

=09John
---1073082115-1139661777-1226343843=:30404--

Re: mod_perl survey results

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

Re: mod_perl survey results

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

>>> - the rate of new people coming into the community has been =20
>>> declining.
>
> The responses there are indeed a bit scary. It feels like we're a =20
> dying breed.
> I believe this is to a large extent a "marketing issue" for perl in =20=

> general, and mod_perl by extension, with regard to the younger =20
> programmers generation. At least in various European countries I =20
> know, perl is not really being taught in programming schools as a =20
> "serious" programming language for applications. These young people =20=

> have all heard the name, but seem to consider it as a powerful but =20
> somewhat messy scripting language to create system administration =20
> scripts.

Frankly, I think that a lot of people thing that Apache/mod_perl is =20
much too big and complex. They tend to prefer small single-process =20
servers, like mongrel, running on lots of ports. FastCGI has many =20
fans, as well. Even AxKit ships with its own fast and light Web =20
server. For adherents of the fast and light server (handle HTTP and =20
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 =20
HTTP. It's fairly easy to implement a new HTTP server, so there are a =20=

lot of them, and many are easy to use and extremely fast. If all =20
you're interested in is serving a Rails or Catalyst app, Apache/=20
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 =20
options out there, and, as has been pointed out elsewhere in this =20
thread, folks who like and use mod_perl seem more interested in =20
getting their jobs done than in evangelizing or marketing. Can't say I =20=

blame them.

Best,

David=

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler 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

Re: mod_perl survey results

> 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

Re: mod_perl survey results

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

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 1:15 PM, Perrin Harkins wrote:
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler 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

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 10:15 AM, Perrin Harkins wrote:
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler 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? :)

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 1:27 PM, David E. Wheeler wrote:
> 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.

What benchmarks won't show is the weird issues Young New Server X will
have on Esoteric Platform Y and all the other real-world pitfalls that
the long-time players in the web server field have dealt with and
worked around over the years (...where "Esoteric" may actually be "any
platform other than the three versions of Linux distro ABC that the
developers tested it on.")

(Yeah, forking, threads, sockets, shared memory, logging, etc. is "old
world tech" and seems like a solved problem, but there are many devils
in those details, IME.)

-John

Re: mod_perl survey results

----- Original Message ----- 2:49 PM, David E. Wheeler
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 prefer to use mod_perl, but this especially because it works under both
Linux and Windows and I need to develop the apps under Windows before using
them under Linux.

However, I've seen that many Catalyst developers prefer to use fastcgi and
not mod_perl, because when using fastcgi, the applications can be restarted
without restarting the whole web server.
Too bad that fastcgi is harder to install than mod_perl or fcgid...

From the perspective of the number of users, mod_perl is usually used by
those who have root access and it is not used for shared hosting. Of course
the number of users is not big, but the importance of those users is bigger.

Octavian

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 2:09 PM, Octavian Rasnita wrote:
> However, I've seen that many Catalyst developers prefer to use fastcgi and
> not mod_perl, because when using fastcgi, the applications can be restarted
> without restarting the whole web server.

It's the same with mod_perl: you can restart your backend server
without touching the frontend proxy server. It's possible that some
FastCGI implementations have a truly seamless way to do this though,
holding requests while the backend restarts. I haven't played with it
enough to know.

- Perrin

Re: mod_perl survey results

Perrin Harkins wrote:
>
> It's the same with mod_perl: you can restart your backend server
> without touching the frontend proxy server. It's possible that some
> FastCGI implementations have a truly seamless way to do this though,
> holding requests while the backend restarts. I haven't played with it
> enough to know.
>
> - Perrin
>
I'd really love to see a best practices kind of document, or at least a
more detailed document that described getting the light front / heavy
backend stuff working. The mp1 guide has a pretty extensive section on
the various options, but it hasn't been updated to reflect apache2/mp2.
It also doesn't address any of the little hoops that need to be jumped
through to get all the ancillary, but important, bits working. Things
like getting backend server authentication info logged on the front end
server, getting the front end remote_ip to the backend server, how to
manage configs between the front and back end. I'm sure there's other
stuff that I'm missing. It'd actually be nice just to see a list of
'things you might not have thought about' that go along with that
configuration model.

I suppose that arguably this is beyond the scope of mod_perl, but if
we're constantly going to trot out the idea that you should be running
in this kind of configuration, we should probably do everything we can
to make deploying that configuration as painless as possible.

Adam

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 3:42 PM, Adam Prime wrote:
> I'd really love to see a best practices kind of document, or at least a more
> detailed document that described getting the light front / heavy backend
> stuff working. The mp1 guide has a pretty extensive section on the various
> options, but it hasn't been updated to reflect apache2/mp2.

There's not much to update about it, except maybe that worker MPM is
good for the frontend.

> It also doesn't
> address any of the little hoops that need to be jumped through to get all
> the ancillary, but important, bits working. Things like getting backend
> server authentication info logged on the front end server, getting the front
> end remote_ip to the backend server, how to manage configs between the front
> and back end.

"Practical mod_perl" covered at least some of that I think.

> I suppose that arguably this is beyond the scope of mod_perl, but if we're
> constantly going to trot out the idea that you should be running in this
> kind of configuration, we should probably do everything we can to make
> deploying that configuration as painless as possible.

Sounds good to me. If you have any contributions for the docs, send 'em in.

- Perrin

Re: mod_perlsurvey results

Perrin Harkins elem.com> writes:

>
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler 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?
>

But you _do_ want to keep static file serving apart from the app code (or else
incur the memory overhead of an app process for every file download), so you do
need to go that frontend/backend route -- and it seems to me that apache behind
a proxy (which may be another apache) is a lot bigger and uglier a beast than
fastcgi behind a webserver (which may be apache).

[ot] Re: mod_perl survey results

Perrin Harkins wrote:
> On Tue, Nov 11, 2008 at 3:42 PM, Adam Prime wrote:
>> I'd really love to see a best practices kind of document, or at least a more
>> detailed document that described getting the light front / heavy backend
>> stuff working. The mp1 guide has a pretty extensive section on the various
>> options, but it hasn't been updated to reflect apache2/mp2.
>
> There's not much to update about it, except maybe that worker MPM is
> good for the frontend.
>


I've been playing with the experimental event MPM for a front end
caching reverse proxy, and have been very happy with the results so far.

-- Douglas Hunter

Re: mod_perl survey results

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.

Not probably... you need perl built for threading, and httpd built for
threading.

There is a very strong probability that httpd 2.4/3.0 will encourage no
"prefork" style servers, and by the following major rev, they will be
discarded altogether. Already apr builds to support threads unless you
are very persistent in telling it "no, thank you".

We will never attain async servers/more-requests-than-children until we
wholly embrace threading, and free-threading at that :)

But your poll doesn't surprise me, Covalent's shipped a threaded perl,
both MPM's for now some 6+ years, and the customers have appreciated it
significantly.

The fact that the PHP project can't persuade people to upgrade 10 year old
non-reentrant libraries doesn't change the fact that several linux vendors
now ship a worker model by default. I'd hope the modperl crew doesn't
follow their nonsensical flip mid-minor-version to make the zts support
"experimental/maintainer" - that was lame :)

It's better to plow through these issues, and then decide based on real
pragmatism and cpu load if prefork or worker is better suited, and then
prepare to embrace the next decade of free threaded applications.

Re: mod_perl survey results

Foo JH wrote:
> 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? :)

Not quite, but close...

http://us.apachecon.com/c/accn2008/

(when this link breaks, substitute cn. for us. --- but dns hasn't caught
up).

Would be cool to have some mod_perl fandom in the house!

Re: [ot] Re: mod_perl survey results

Douglas Hunter wrote:
> I've been playing with the experimental event MPM for a front end
> caching reverse proxy, and have been very happy with the results so far.
ditto. Witness it in use here:

http://ridecharge.com

PXY: httpd 2.2.9 w/ event mpm
Cache: X
APP: mongrel

mongrel's replacement passenger took the mod_perl type approach.
which I haven't played with yet, but will be soon.

For people that think mod_perl is heavy, mongrels are just as heavy.

mongrel processors = 5
mongrels = 12

size / mongrel process = 225 MB

Thats ~4GB / app box already and less < 2 years dev.

I'd mention that Ticketmaster's httpd/mod_perl backend app severs had
sizes of ~160MB and have over 400,000 lines of perl code, and 1700 packages.

We have not even close to that much in the mongrels.





--
------------------------------------------------------------ ------------
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior System Admin - RideCharge, Inc. http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 7:46 PM, Andrew Rodland wrote:
> But you _do_ want to keep static file serving apart from the app code (or else
> incur the memory overhead of an app process for every file download), so you do
> need to go that frontend/backend route -- and it seems to me that apache behind
> a proxy (which may be another apache) is a lot bigger and uglier a beast than
> fastcgi behind a webserver (which may be apache).

This is what I'm talking about -- people have "a feeling" that apache
is somehow "heavy" but no concrete reason for it. Apache HTTPD has a
very small footprint and is very efficient. It's been saturating
people's bandwidth from Pentium I boxes for years. The thing that
takes all the resources here is perl, and it's the same perl in both
cases.

- Perrin

Re: mod_perl survey results

William A. Rowe, Jr. wrote:
> Foo JH wrote:
>> 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? :)
>
> Not quite, but close...
>
> http://us.apachecon.com/c/accn2008/
Thanks. Only 1 small comment: Singapore is not exactly next door to
China. In fact we're closer to Indonesia than the former!

Re: mod_perl survey results

On Tue, Nov 11, 2008 at 7:33 PM, Joel Bernstein wrote:
> 2008/11/11 Perrin Harkins :
>> On Tue, Nov 11, 2008 at 2:09 PM, Octavian Rasnita wrote:
>>> However, I've seen that many Catalyst developers prefer to use fastcgi and
>>> not mod_perl, because when using fastcgi, the applications can be restarted
>>> without restarting the whole web server.
>>
>> It's the same with mod_perl: you can restart your backend server
>> without touching the frontend proxy server. It's possible that some
>> FastCGI implementations have a truly seamless way to do this though,
>> holding requests while the backend restarts. I haven't played with it
>> enough to know.
>
> It's actually better than that. Typically in such a deployment you'd
> be using either a standalone FCGI process manager, or one built into
> the web application or web framework (the Catalyst FastCGI server has
> such a feature) then it's as simple as starting up a new version of
> the app, then shutting down the old one.
>
> All FastCGI child processes share a single unix domain socket on the
> filesystem, which is opened both by the child processes AND the
> webserver without O_EXCL, so the webserver continues to push requests
> down the socket, and whichever FastCGI process's accept() wins (this
> is up to the OS kernel) gets to serve the request.
>
> As long as you shut down the old version of the app after the new
> version is started, there's a completely seamless handover with total
> isolation from the webserver. The scheduling of request handling by a
> pool of backend appservers, again, is handled by the kernel rather
> than the webserver. This seems to me to be a good example of the Unix
> way of multiple processes handling one thing well.
>
> In the typical mod_perl deployment of a lightweight apache mod_proxy
> delegating requests to a mod_perl backend, I think the same thing
> could be achieved if both can be persuaded open the network socket
> between them without O_EXCL - then you can startup the new mod_perl
> appserver in tandem with the old, seamlessly the proxy will switch
> requests to the new one, and you can shutdown the old appserver. I'm
> not at all familiar with the apache internals though, so somebody
> else's comments on how possible this would be, are definitely
> appreciated.

Now _that's_ a great feature. There are proxy servers that will do
this for mod_perl, but I'm not aware of a way to do it while using
apache as your frontend proxy. Maybe mod_proxy_balancer could be made
to do it?

- Perrin