Mailing List Archive: ModPerl: ModPerl

mod_perl survey results

1 2

View All

Index | Next | Previous | View Threaded

siracusa at gmail

Nov 11, 2008, 10:49 AM

Post #26 of 36 (664 views)
Permalink

Re: mod_perl survey results [In reply to]

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

orasnita at gmail

Nov 11, 2008, 11:09 AM

Post #27 of 36 (677 views)
Permalink

Re: mod_perl survey results [In reply to]

----- Original Message ----- 2:49 PM, David E. Wheeler
<david [at] kineticode> 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

perrin at elem

Nov 11, 2008, 11:15 AM

Post #28 of 36 (666 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 2:09 PM, Octavian Rasnita <orasnita [at] gmail> 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

adam.prime at utoronto

Nov 11, 2008, 12:42 PM

Post #29 of 36 (672 views)
Permalink

Re: mod_perl survey results [In reply to]

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

perrin at elem

Nov 11, 2008, 1:09 PM

Post #30 of 36 (665 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 3:42 PM, Adam Prime <adam.prime [at] utoronto> 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

arodland at comcast

Nov 11, 2008, 4:46 PM

Post #31 of 36 (666 views)
Permalink

Re: mod_perl survey results [In reply to]

Perrin Harkins <perrin <at> elem.com> writes:

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

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

wrowe at rowe-clan

Nov 11, 2008, 7:30 PM

Post #32 of 36 (667 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.

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.

wrowe at rowe-clan

Nov 11, 2008, 7:35 PM

Post #33 of 36 (667 views)
Permalink

Re: mod_perl survey results [In reply to]

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!

perrin at elem

Nov 11, 2008, 8:45 PM

Post #34 of 36 (656 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 7:46 PM, Andrew Rodland <arodland [at] comcast> 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

jhfoo-ml at extracktor

Nov 12, 2008, 8:18 AM

Post #35 of 36 (656 views)
Permalink

Re: mod_perl survey results [In reply to]

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!

perrin at elem

Nov 12, 2008, 8:31 AM

Post #36 of 36 (661 views)
Permalink

Re: mod_perl survey results [In reply to]

On Tue, Nov 11, 2008 at 7:33 PM, Joel Bernstein <joel [at] fysh> wrote:
> 2008/11/11 Perrin Harkins <perrin [at] elem>:
>> On Tue, Nov 11, 2008 at 2:09 PM, Octavian Rasnita <orasnita [at] gmail> 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

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads