You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Philip Mak <pm...@aaanime.net> on 2002/11/26 11:15:25 UTC
Apache 2?
These days, Apache 2 has become the default version of Apache.
On my site, I run a front end Apache and a back end Apache.
Front end: Apache 1.x, has mod_accel module which is like mod_proxy,
but downloads all the data from the backend ASAP and frees it up
immediately, so that a slow modem doesn't tie up the backend
Back end: Apache 1.x with mod_perl
Here's my question:
Is it worth upgrading to Apache 2.x for either the front end or back
end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
Posted by Stas Bekman <st...@stason.org>.
Issac Goldstand wrote:
> ----- Original Message -----
> From: "Stas Bekman" <st...@stason.org>
> . Since if your mod_perl handler sends
>
>>the data to a thread which runs a filter that send the data to a client
>>(and doesn't need perl) it'll still block on the network transfer, which
>>will block the response handler sending the data. So I can imagine that
>>we will need a special filter that buffers the data, immediately
>>releasing the perl handler and then slowly feeding it to the the client.
>
>
> This isn't just a mod_perl thing, either. This would be a generic Apache2
> thing. *ANY* content should be filtered as such through a 2-tier system
> like this - but I thought that's what the bucket brigades did. Please
> correct me if I'm wrong in this picture:
>
> Response Handler ----> start of buckets ----> Filter API ----> End of
> buckets ----> Core Output ----> client
>
> it was my understanding that one of the purposes of the core-output filter
> was to do exactly what we want - free the backend request and filter threads
> once they've finished with the EOS bucket. Am I missing something?
From a quick read through:
server/core.c:static apr_status_t core_output_filter(ap_filter_t *f,
apr_bucket_brigade *b)
I don't think core_output_filter does anything to buffer up the data and
release the handler. The only buffering it does is if it doesn't have
*enough* bytes to send so it waits for the next brigade.
In order to understand how the new model works you really have run the
snooping filter and study the output. The important outcome that you
gain is that filters are called in a pipeline, i.e. the response handler
sends a portion of data to the first filter, which immediately passes
that data to the next filter, and so on, while all previous filters that
have already passed the first chunk await for the latter filters to
return. That's my understanding so far, please correct me if I'm wrong.
So if you want to release the handler asap, you need a filter that will
buffer up the data and feed it to the remaining filters at the speed
they request. It should probably be inserted just before the
core_output_filter, so all the processings will be already completed by
that time. Think of it as an extension to the core_output_filter which
buffers things up. And the cool thing is that you can inject it only
when you want it, e.g. you don't want it for non-mod_perl requests.
And of course it's not mod_perl specific like you've mentioned, but I
don't really know of any other producers that consume a lot of memory
and therefore for which we want to minimize their number and keep them
busy for real all the time.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Posted by Issac Goldstand <ma...@beamartyr.net>.
----- Original Message -----
From: "Stas Bekman" <st...@stason.org>
To: "Philip Mak" <pm...@aaanime.net>
Cc: <mo...@apache.org>
Sent: Wednesday, November 27, 2002 2:24 AM
Subject: Re: Apache 2?
. Since if your mod_perl handler sends
> the data to a thread which runs a filter that send the data to a client
> (and doesn't need perl) it'll still block on the network transfer, which
> will block the response handler sending the data. So I can imagine that
> we will need a special filter that buffers the data, immediately
> releasing the perl handler and then slowly feeding it to the the client.
This isn't just a mod_perl thing, either. This would be a generic Apache2
thing. *ANY* content should be filtered as such through a 2-tier system
like this - but I thought that's what the bucket brigades did. Please
correct me if I'm wrong in this picture:
Response Handler ----> start of buckets ----> Filter API ----> End of
buckets ----> Core Output ----> client
it was my understanding that one of the purposes of the core-output filter
was to do exactly what we want - free the backend request and filter threads
once they've finished with the EOS bucket. Am I missing something?
Issac
Re: Apache 2?
Posted by Stas Bekman <st...@stason.org>.
Philip Mak wrote:
> These days, Apache 2 has become the default version of Apache.
>
> On my site, I run a front end Apache and a back end Apache.
>
> Front end: Apache 1.x, has mod_accel module which is like mod_proxy,
> but downloads all the data from the backend ASAP and frees it up
> immediately, so that a slow modem doesn't tie up the backend
>
> Back end: Apache 1.x with mod_perl
>
> Here's my question:
>
> Is it worth upgrading to Apache 2.x for either the front end or back
> end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Theoretically with mod_perl 2.0 with Apache2.0 threaded mpms
architecture the need for the front-end/back-end solution has gone away,
because now you can have a few threads running Perl interpreters and
many other threads which don't run Perl interpreters. So the front-end
and the back-end can now co-exist on the same server. Practically we
still need to work out the details. Since if your mod_perl handler sends
the data to a thread which runs a filter that send the data to a client
(and doesn't need perl) it'll still block on the network transfer, which
will block the response handler sending the data. So I can imagine that
we will need a special filter that buffers the data, immediately
releasing the perl handler and then slowly feeding it to the the client.
The prototype can be written in perl and then probably better ported
to C. You can use the MyApache::FilterSnoop
(http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter)
to trace the data propogation through filters.
Of course first you need to understand the 2.0 architecture, which is
discussed in details at http://perl.apache.org/docs/2.0/user/index.html
(Part IV: mod_perl Handlers). As this is a new documentation please help
to improve it. Especially if you have more interesting examples, than
the ones I've come up with.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Philip" == Philip Mak <pm...@aaanime.net> writes:
Philip> Let's say you have a mod_perl page that returns a 100k document, and a
Philip> 28.8k modem downloads that document.
Philip> The mod_perl process that is serving that document will be tied up
Philip> until that modem finishes downloading the document, which is
Philip> inefficient since the mod_perl processes take up a lot of memory. A
Philip> lightweight front-end proxy that loads the data from the mod_perl
Philip> process all at once and then feeds it to the modem would save memory.
Yeah, I did this to stonehenge.com about five months ago, and am now handling
about 3-4 times the traffic for the same loadav. All on one machine.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Apache 2?
Posted by Stas Bekman <st...@stason.org>.
Philip Mak wrote:
> On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote:
>
>>Is there any documention of a HOWTO or a tutorial about a lightweight
>>front-end proxy that loads the data from the mod_perl
>
>
> I wrote a guide a while back on how to install mod_accel and
> mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it
> will work with Apache 2.x.
> http://www.aaanime.net/pmak/apache/mod_accel/
and of course your perl.apache.org docs:
http://perl.apache.org/docs/1.0/guide/strategy.html
http://perl.apache.org/docs/1.0/guide/scenario.html
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Posted by Philip Mak <pm...@aaanime.net>.
On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote:
> Is there any documention of a HOWTO or a tutorial about a lightweight
> front-end proxy that loads the data from the mod_perl
I wrote a guide a while back on how to install mod_accel and
mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it
will work with Apache 2.x.
http://www.aaanime.net/pmak/apache/mod_accel/
Re: Apache 2?
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "GC" == Grant Cooper <gr...@nucleus.com> writes:
GC> Is there any documention of a HOWTO or a tutorial about a lightweight
GC> front-end proxy that loads the data from the mod_perl
try this: perldoc mod_perl_tuning
It comes with mod_perl, conveniently. Nobody has sent me any updates
in two years, so I assume nobody has come up with anything better ;-)
I still use the proxypass thing with front end running SSL and back
end doing all the heavy lifting in Template Toolkit. I call that my
"application server" to let the buzz-word compliant be happy.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache 2?
Posted by Grant Cooper <gr...@nucleus.com>.
Is there any documention of a HOWTO or a tutorial about a lightweight
front-end proxy that loads the data from the mod_perl
----- Original Message -----
From: "Philip Mak" <pm...@aaanime.net>
To: "Grant Cooper" <gr...@nucleus.com>
Cc: <mo...@apache.org>
Sent: Tuesday, November 26, 2002 10:46 AM
Subject: Re: Apache 2?
> On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote:
> > What do yo mean a modem will tie up the Server? I've never heard this
> > before.
>
> Let's say you have a mod_perl page that returns a 100k document, and a
> 28.8k modem downloads that document.
>
> The mod_perl process that is serving that document will be tied up
> until that modem finishes downloading the document, which is
> inefficient since the mod_perl processes take up a lot of memory. A
> lightweight front-end proxy that loads the data from the mod_perl
> process all at once and then feeds it to the modem would save memory.
Re: Apache 2?
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Tue, 26 Nov 2002, Philip Mak wrote:
> On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote:
> > What do yo mean a modem will tie up the Server? I've never heard this
> > before.
>
> Let's say you have a mod_perl page that returns a 100k document, and a
> 28.8k modem downloads that document.
>
> The mod_perl process that is serving that document will be tied up
> until that modem finishes downloading the document, which is
> inefficient since the mod_perl processes take up a lot of memory. A
> lightweight front-end proxy that loads the data from the mod_perl
> process all at once and then feeds it to the modem would save memory.
Things are bit complicated. Kernel can buffer some part of document and
there is Apache feature named lingering close. For example, client's
speed is 3K/s. If you have 64K kernel TCP send buffer then mod_perl
will write 64K very soon but it will wait about 12 seconds to write other 36K.
And after mod_perl will have written these 36K it will wait 2 second in
lingering close.
Even you increase kernel TCP send buffer (it's not always good idea) to 100K
anyway you still 2 second lingering close delay for slow clients.
Note that you never see lingering close state in /server-status (at least
in Apache 1.3) - such processes are marked as idle but they are not really
idle - they can not handle requests.
Also lingering close time is not accounted in %T directive in the log.
You can only estimate the count of Apache processes that is in linegring close
state using netstat utulity and looking for FIN_WAIT2 socket states.
Igor Sysoev
http://sysoev.ru/en/
Re: Apache 2?
Posted by Philip Mak <pm...@aaanime.net>.
On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote:
> What do yo mean a modem will tie up the Server? I've never heard this
> before.
Let's say you have a mod_perl page that returns a 100k document, and a
28.8k modem downloads that document.
The mod_perl process that is serving that document will be tied up
until that modem finishes downloading the document, which is
inefficient since the mod_perl processes take up a lot of memory. A
lightweight front-end proxy that loads the data from the mod_perl
process all at once and then feeds it to the modem would save memory.
Re: Apache 2?
Posted by Grant Cooper <gr...@nucleus.com>.
What do yo mean a modem will tie up the Server? I've never heard this
before.
----- Original Message -----
From: "Philip Mak" <pm...@aaanime.net>
To: <mo...@apache.org>
Sent: Tuesday, November 26, 2002 2:15 AM
Subject: Apache 2?
> These days, Apache 2 has become the default version of Apache.
>
> On my site, I run a front end Apache and a back end Apache.
>
> Front end: Apache 1.x, has mod_accel module which is like mod_proxy,
> but downloads all the data from the backend ASAP and frees it up
> immediately, so that a slow modem doesn't tie up the backend
>
> Back end: Apache 1.x with mod_perl
>
> Here's my question:
>
> Is it worth upgrading to Apache 2.x for either the front end or back
> end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
Posted by "Jason Czerak (Jasnik)" <Ja...@Jasnik.net>.
On Tue, 2002-11-26 at 05:15, Philip Mak wrote:
Is the 'front end' and 'back end' apache servers on the 'same box'?
My problme is that I had one web server. and I did the FE and BE bit (BE
being on the loop back address). to free up some major resources since
mod_perl apache gets huges. I didn't need 20meg process serving up 2K
images :) and had about 20 to 30 smaller apache process doing the
'static' content serving.
I'm currently running Apache2 in a development enviroment. Going to be
upgradeing my web servers with 2.0. Most sites will work nicly.
I have found that the memory resource problem doesn't excist with 2.0
when you compile with 'worker' or fully threaded. I'm running 2
processes of apache and each of htem have like 20 threaded. performce
seems good with just running one apache server. didn't do any real load
testing, but I'm sure 2.0 is going to blow 1.3.x away.
--
Jason
> These days, Apache 2 has become the default version of Apache.
>
> On my site, I run a front end Apache and a back end Apache.
>
> Front end: Apache 1.x, has mod_accel module which is like mod_proxy,
> but downloads all the data from the backend ASAP and frees it up
> immediately, so that a slow modem doesn't tie up the backend
>
> Back end: Apache 1.x with mod_perl
>
> Here's my question:
>
> Is it worth upgrading to Apache 2.x for either the front end or back
> end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
>
Re: Apache 2?
Posted by Stas Bekman <st...@stason.org>.
> 3. If you have different sites (presumably owned by different people)
> on your server, all the backend servers can execute with different
> userids so that the backend server of one site doesn't have to be able
> to read the files of another site. And, everyone can change their own
> server configuration.
>
> We know that Apache 2 confers benefit #1 without needing a separate
> frontend and backend. Benefit #2 seems to be planned, but isn't here
> yet. ...What about benefit #3?
#3: --with-mpm=perchild
which is a work in progress
http://httpd.apache.org/docs-2.0/mod/perchild.html
notice the new AssignUserID and ChildPerUserID directives which now can
set different uid/gid for each group of processes/threads.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2?
Posted by Philip Mak <pm...@aaanime.net>.
On Sat, Nov 30, 2002 at 12:45:50PM -0500, Jason Czerak (Jasnik) wrote:
> Is the 'front end' and 'back end' apache servers on the 'same box'?
> My problme is that I had one web server. and I did the FE and BE bit
> (BE being on the loop back address). to free up some major resources
> since mod_perl apache gets huges. I didn't need 20meg process
> serving up 2K images :) and had about 20 to 30 smaller apache
> process doing the 'static' content serving.
Yes, that's exactly what I do.
> I have found that the memory resource problem doesn't excist with
> 2.0 when you compile with 'worker' or fully threaded. I'm running 2
> processes of apache and each of htem have like 20 threaded.
> performce seems good with just running one apache server. didn't do
> any real load testing, but I'm sure 2.0 is going to blow 1.3.x away.
Well, there's multiple benefits of running a separate frontend and
backend server:
1. As stated above, the static HTML/GIF/JPG/etc. files don't have to
be served by the heavyweight mod_perl process.
2. If the backend is serving a large file, the frontend can retrieve
the entire file from the backend and free it up immediately, so that a
client with a slow modem will not tie up the backend for the time it
takes to download.
3. If you have different sites (presumably owned by different people)
on your server, all the backend servers can execute with different
userids so that the backend server of one site doesn't have to be able
to read the files of another site. And, everyone can change their own
server configuration.
We know that Apache 2 confers benefit #1 without needing a separate
frontend and backend. Benefit #2 seems to be planned, but isn't here
yet. ...What about benefit #3?