You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <ia...@cnet.com> on 2001/04/20 06:30:20 UTC
mod_include performance numbers
hi.
I have been running some tests on the performance of mod_include /
filters on
heavy traffic websites.
the test results are available at http://webpref.org/mstone/
what I did.
test situation.
1000 files of the same size, all in the same directory. (representing
our front door page news.com)
1 E4500 (8 way) box running solaris 2.6
I edited out the header and footer section of the page into virtual
include calls, and made 3 different instances
1 with no virutal includes,
1 with the header virtual included
1 with the both virtual included.
the files all pointed to the same header and footer file (which is what
it would be like in production)
raw (no filter): 341 reqs/sec load avg: max at 3.5
using Files Match to set the filter, and having the filter on the
header/footer file.
0 includes: 282 req/sec load avg: ~11
1 includes: 256 req/sec load avg: ~11.5
2 includes: 235 req/sec load avg: ~12
using Location on just the main file
2 includes: 269 req/sec load avg: ~14
using a cut down version, which has no env variables set, and only the
'include' command registered
(I commented out 2 sections of code)
2 includes: 279 req/sec load avg: ~7.1
I'm not sure if this means that ALL filters are slow, or if
it is just mod-include.
I also have some truss output for these, and I'll put them on the site
if anyone wants to see what is going on.
Cheers
Ian
Re: memory allocation (was Re: mod_include performance numbers)
Posted by Greg Ames <gr...@remulak.net>.
Cliff Woolley wrote:
>
> On Sat, 21 Apr 2001, Greg Ames wrote:
>
> > are you thinking about an atomic push/pop block allocator? I'll be
> > happy to help out if so, especially with the machine instruction level
> > stuff.
>
> Yes, I am, and I definitely *will* need help from various people getting
> the appropriate machine language magic for their platforms working. I've
> already done the generic fallback locking implementation of the stack;
> that was simple.
Cool! that's got to be the first piece.
>
> > yeah, but that stuff can go away. compare-and-exchange (or compare &
> > swap, or load & reserve, or...) is our friend in multithreaded systems,
> > especially on multiprocessors. The piece I haven't figured out is how
> > to set up CPU architecture dependent directories, or macros, or
> > whatever, in APR. <sigh>
>
> THAT's the problem. No other piece of APR is *architecture* dependent.
> There's an "arch" include directory, but it's really a misnamed "os"
> directory. I've got a scheme implemented that gives us an APR_ARCH_IS_foo
> macro, but it's a hack. It disobeys the typical APR rule of "all macros
> are always defined and have a value of 0 or 1" and is just defined or not.
> I've also been afraid that some of the possible ways to implement these
> machine-language tricks will also be *compiler* dependent, not just
> architecture dependent. If so, then that makes this that much harder.
Yessir...on platforms that have multiple compilers, there could be
multiple ways of
coding the same machine instruction, or no support at all. This sounds
like something autoconf tests could figure out.
On the other hand, if gcc is running on i486 or above, it shouldn't
matter if it's Linux or FreeBSD or whatever. So if we figure out one of
those platforms, we get a lot of bang for the buck.
> For example, I've taken your jstack.h
jstack == Jeff's stack. I can only take credit for teaching him some
things about atomic updates on multiprocessors.
> and pulled out the __cds() "calls"
> and wrapped a macro around them so that different architectures can insert
> their equivalent instruction. But are "__cds()" and "cds_t" available on
> all S390 platforms? I'm guessing no. Ugh.
I'm guessing you're right, I doubt if gcc supports it (Linux390). But
autoconf is our friend. (sheesh...did I really say that? )
> If anybody has a clean way to do this, I'm all ears.
Me too. More ideas are greatly appreciated.
Greg
Re: memory allocation (was Re: mod_include performance numbers)
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sat, 21 Apr 2001, dean gaudet wrote:
> can you give a short description of this allocator?
FirstBill wrote the beginnings of it. It's basically a drop-in
replacement for malloc/calloc/free (really a wrapper around them) that,
when initialized, pre-allocates blocks of various sizes (in FirstBill's,
IIRC, it does as many blocks of a given power-of-two size as will fit in
8KB).
It uses a simple stack to keep its free lists. The stack, while simple in
concept, is the tricky-in-implementation part. The idea is that the stack
API just has three operations: init/push/pop. That's it. On many
platforms, a stack like this can be implemented without locks, using
architecture-specific instructions like Compare-Double-and-Swap.
So it's really just a wrapper around malloc that keeps stacks of blocks
that can be very efficiently re-allocated.
That's it.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: memory allocation (was Re: mod_include performance numbers)
Posted by dean gaudet <dg...@arctic.org>.
can you give a short description of this allocator?
-dean
On Sat, 21 Apr 2001, Cliff Woolley wrote:
> On Sat, 21 Apr 2001, Greg Ames wrote:
>
> > are you thinking about an atomic push/pop block allocator? I'll be
> > happy to help out if so, especially with the machine instruction level
> > stuff.
>
> Yes, I am, and I definitely *will* need help from various people getting
> the appropriate machine language magic for their platforms working. I've
> already done the generic fallback locking implementation of the stack;
> that was simple. And I have what you and Jeff gave me for S390. But...
>
> > yeah, but that stuff can go away. compare-and-exchange (or compare &
> > swap, or load & reserve, or...) is our friend in multithreaded systems,
> > especially on multiprocessors. The piece I haven't figured out is how
> > to set up CPU architecture dependent directories, or macros, or
> > whatever, in APR. <sigh>
>
> THAT's the problem. No other piece of APR is *architecture* dependent.
> There's an "arch" include directory, but it's really a misnamed "os"
> directory. I've got a scheme implemented that gives us an APR_ARCH_IS_foo
> macro, but it's a hack. It disobeys the typical APR rule of "all macros
> are always defined and have a value of 0 or 1" and is just defined or not.
> I've also been afraid that some of the possible ways to implement these
> machine-language tricks will also be *compiler* dependent, not just
> architecture dependent. If so, then that makes this that much harder.
> For example, I've taken your jstack.h and pulled out the __cds() "calls"
> and wrapped a macro around them so that different architectures can insert
> their equivalent instruction. But are "__cds()" and "cds_t" available on
> all S390 platforms? I'm guessing no. Ugh. If anybody has a clean way to
> do this, I'm all ears.
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
memory allocation (was Re: mod_include performance numbers)
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sat, 21 Apr 2001, Greg Ames wrote:
> are you thinking about an atomic push/pop block allocator? I'll be
> happy to help out if so, especially with the machine instruction level
> stuff.
Yes, I am, and I definitely *will* need help from various people getting
the appropriate machine language magic for their platforms working. I've
already done the generic fallback locking implementation of the stack;
that was simple. And I have what you and Jeff gave me for S390. But...
> yeah, but that stuff can go away. compare-and-exchange (or compare &
> swap, or load & reserve, or...) is our friend in multithreaded systems,
> especially on multiprocessors. The piece I haven't figured out is how
> to set up CPU architecture dependent directories, or macros, or
> whatever, in APR. <sigh>
THAT's the problem. No other piece of APR is *architecture* dependent.
There's an "arch" include directory, but it's really a misnamed "os"
directory. I've got a scheme implemented that gives us an APR_ARCH_IS_foo
macro, but it's a hack. It disobeys the typical APR rule of "all macros
are always defined and have a value of 0 or 1" and is just defined or not.
I've also been afraid that some of the possible ways to implement these
machine-language tricks will also be *compiler* dependent, not just
architecture dependent. If so, then that makes this that much harder.
For example, I've taken your jstack.h and pulled out the __cds() "calls"
and wrapped a macro around them so that different architectures can insert
their equivalent instruction. But are "__cds()" and "cds_t" available on
all S390 platforms? I'm guessing no. Ugh. If anybody has a clean way to
do this, I'm all ears.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: mod_include performance numbers
Posted by Greg Ames <gr...@remulak.net>.
Cliff Woolley wrote:
>
>
> Still on my plate (I'll get it done soon, I swear) is the new memory
> allocation scheme for buckets,
are you thinking about an atomic push/pop block allocator? I'll be
happy to help out if so, especially with the machine instruction level
stuff.
> With threading enabled, the poor buckets code
> spends half its time trying to acquire mutexes. <sigh>
>
yeah, but that stuff can go away. compare-and-exchange (or compare &
swap, or load & reserve, or...) is our friend in multithreaded systems,
especially on multiprocessors. The piece I haven't figured out is how
to set up CPU architecture dependent directories, or macros, or
whatever, in APR. <sigh>
Greg
Re: mod_include performance numbers
Posted by Cliff Woolley <cl...@yahoo.com>.
On Fri, 20 Apr 2001, Paul J. Reder wrote:
> I'm sure that there are some aspects of mod_include that can be improved,
> but the fact of the matter is that a filter that looks at every byte across
> buckets and brigades is going to slow things down. With 2.0 admins will
> need to do a more judicious job of bringing filters into play (like not
> running all .html and .shtml files through mod_include).
Clearly.
> > I also have some truss output for these, and I'll put them on the site
> > if anyone wants to see what is going on.
>
> I would love to see any performance or profiling information that you have.
> The more info, the better the solution.
Still on my plate (I'll get it done soon, I swear) is the new memory
allocation scheme for buckets, which should reduce many of the problems
that filters/bucket brigades in general are currently having
performance-wise. I'd not be surprised at all if a truss of what's there
currently shows lots of time spent in malloc/free, especially on a
threaded MPM. We've seen it before, and I've no reason to believe that
this is any different. With threading enabled, the poor buckets code
spends half its time trying to acquire mutexes. <sigh>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: mod_include performance numbers
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Marc Slemko wrote:
>
> On Fri, 20 Apr 2001, Paul J. Reder wrote:
>
> > Ian Holsman wrote:
> > > I'm not sure if this means that ALL filters are slow, or if
> > > it is just mod-include.
> >
> > I'm sure that there are some aspects of mod_include that can be improved,
> > but the fact of the matter is that a filter that looks at every byte across
> > buckets and brigades is going to slow things down. With 2.0 admins will
> > need to do a more judicious job of bringing filters into play (like not
> > running all .html and .shtml files through mod_include).
>
> Umh... that's bogus. There is no reason and no way that simply having a
> file parsed for SSIs should have to be that slow. I hope there is
> something very not right here (ie. room for big performance improvements)
> causing very poor results, but SSIs have always been quite cheap to parse
> (despite what people like saying; traditionally, any overhead has been
> more in the loss of cachability), and it seems pretty weak to take such a
> massive performance hit. What mod_include is doing is quite simple, and
> running some simple pattern matching over the output just shouldn't be all
> that expensive when the CPU cycles required should be so cheap.
>
> Lots of sites base lots of stuff on using a bunch of includes. I just
> want to point out that saying "well, admins will just have to use less
> includes" is not any sort of answer.
I didn't say "admins will just have to use less includes". I said admins might
have to be more careful about allowing things that don't use includes to be
run through the filter.
And, yes, there are things that leave room for improvement in the filter code.
The biggest piece of overhead is on the bucket allocation code. In my profiling
the malloc and free code was always tops. It made it tough to identify anything
in mod_include itself. So, for the moment, it isn't bogus to say that a filter
- any filter - will provide some processing expense.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: mod_include performance numbers
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
>
> dean gaudet wrote:
> >
> > so, like, this zero-copy bucket/filter stuff.
> >
> > it was supposed to make things faster eh?
> >
>
> It sure slowed things down in my last job...deja vu.
>
...zero copy, that is.
Q: If it costs 300 "typical" instructions worth of cycles to move a
1500 byte ethernet packet,
how many instructions should you spend trying to avoid moving it?
A: <left for the reader>
It gets worse if you're talking little bitty pieces of HTML.
Greg
Re: mod_include performance numbers
Posted by Greg Ames <gr...@remulak.net>.
dean gaudet wrote:
>
> so, like, this zero-copy bucket/filter stuff.
>
> it was supposed to make things faster eh?
>
It sure slowed things down in my last job...deja vu.
Greg
Re: mod_include performance numbers
Posted by dean gaudet <dg...@arctic.org>.
so, like, this zero-copy bucket/filter stuff.
it was supposed to make things faster eh?
-dean
Re: mod_include performance numbers
Posted by Cliff Woolley <cl...@yahoo.com>.
On Fri, 20 Apr 2001, Paul J. Reder wrote:
> Thanks Cliff, I couldn't have said it better, except that I believe that even
> on MMAP systems some price is paid whenever an SSI tag is found and replaced.
> The replacement content for the tag gets put into newly allocated buckets which
> I believe are malloced even if the rest of the content is MMAPed. So the
> bucket/brigade reuse pool would be VERY helpful.
I thought of that after I hit send. You're 100% correct. So let me
revise what I said to "the performance hit is significantly exaggerated on
platforms without MMAP, but MMAP alone doesn't get rid of all the
problems."
At any rate, the summary still stands: it's malloc and free that are
killing us.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: mod_include performance numbers
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Cliff Woolley wrote:
>
> On Fri, 20 Apr 2001, Marc Slemko wrote:
>
> > Umh... that's bogus. There is no reason and no way that simply having a
> > file parsed for SSIs should have to be that slow. I hope there is
> > something very not right here (ie. room for big performance improvements)
> > causing very poor results, but SSIs have always been quite cheap to parse
> > (despite what people like saying; traditionally, any overhead has been
> > more in the loss of cachability), and it seems pretty weak to take such a
> > massive performance hit. What mod_include is doing is quite simple, and
> > running some simple pattern matching over the output just shouldn't be all
> > that expensive when the CPU cycles required should be so cheap.
>
> To clarify, this is not nearly as much of a problem for platforms with
> MMAP. It's platforms without it that have to read in the whole file to a
> bunch of 8KB heap buckets that have issues. The problems there are mainly
> a bazillion mallocs/frees, as I said in my last message. I've gotten rid
> of as many extraneous ones as I can already, and the rest are fixable with
> a bit of judicious memory reuse for buckets, which is on the way.
>
> In short, don't blame mod_include... blame the buckets. For now, anyway.
> =-)
Thanks Cliff, I couldn't have said it better, except that I believe that even
on MMAP systems some price is paid whenever an SSI tag is found and replaced.
The replacement content for the tag gets put into newly allocated buckets which
I believe are malloced even if the rest of the content is MMAPed. So the
bucket/brigade reuse pool would be VERY helpful.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: mod_include performance numbers
Posted by Cliff Woolley <cl...@yahoo.com>.
On Fri, 20 Apr 2001, Marc Slemko wrote:
> Umh... that's bogus. There is no reason and no way that simply having a
> file parsed for SSIs should have to be that slow. I hope there is
> something very not right here (ie. room for big performance improvements)
> causing very poor results, but SSIs have always been quite cheap to parse
> (despite what people like saying; traditionally, any overhead has been
> more in the loss of cachability), and it seems pretty weak to take such a
> massive performance hit. What mod_include is doing is quite simple, and
> running some simple pattern matching over the output just shouldn't be all
> that expensive when the CPU cycles required should be so cheap.
To clarify, this is not nearly as much of a problem for platforms with
MMAP. It's platforms without it that have to read in the whole file to a
bunch of 8KB heap buckets that have issues. The problems there are mainly
a bazillion mallocs/frees, as I said in my last message. I've gotten rid
of as many extraneous ones as I can already, and the rest are fixable with
a bit of judicious memory reuse for buckets, which is on the way.
In short, don't blame mod_include... blame the buckets. For now, anyway.
=-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
RE: mod_include performance numbers
Posted by "Jeffrey A. Stuart" <js...@neo.rr.com>.
Comment's interspersed...
-----Original Message-----
From: gregames@Mail.MeepZor.Com [mailto:gregames@Mail.MeepZor.Com]On Behalf Of
Greg Ames
Sent: Saturday, April 21, 2001 1:59 AM
To: new-httpd@apache.org
Subject: Re: mod_include performance numbers
"Jeffrey A. Stuart" wrote:
>
> I'd like to amen that... I'm starting to see something here that's
concerning
> me. I think that some of the developers have lost touch with what we as web
> admins need.
Welcome aboard, Jeff! I hope we can convince you that we're not all out
of touch.
> We need a server that does following (in order I think.) (and
> all of this of course is IMHO):
>
> 1) A stable server
We've had apache.org running very well on Apache 2.0 for about a month
and a half now, with only two core dumps. Before that, we were on 2.0
since about Feb 15 but it was dumping so frequently
that I wouldn't call it stable. This is with the prefork mpm - the
threaded mpm's have "issues" still ;-)
Is it now... HMM... that is interesting... I didn't know that... Me thinks I
may have to download the latest beta apache and see how it behaves...
> 2) One that isn't too memory intensive out of the box.
> 3) One that is fast.
> 4) One that lets us use SSI. (LOTS AND LOTS of sites use SSI...)
> 5) One that lets us tune our heavy/light weight servers better. (One of the
> things that I've been waiting for is Apache 2.0 and mod_perl 2.0.
You got me there...mod_perl isn't ready yet AFAIK.
Yes... However, please understand, I don't expect that the Apache group to
work on mod_perl... :) There are other people for that... :D
> With
> Apache's threaded MPM, this LOOKS like we can really tune apache such that
our
> mod_perl procs won't be SOO big... And with some of the stuff that was
talked
> about with mod_perl 2.0, it looks like we'll really be able to cut some more
> of the memory out.)
> 6) One that all it basically does is serve web pages. I do NOT need another
> email server, another proxy server, another FTP server, another you name
it...
> ;)
I hear you...it doesn't make sense to me either.
But I don't mind some of Apache's code being used in a separate
one-server-fits-all project. I just won't choose to spend any time
working on it myself.
I don't mind that at all myself... Make it a separate branch on CVS. :) Or a
separate project or whatever. Just not a part of apache 2.0 IMNSHO.
>
> First, the part about making apache a multi-proto server while nice, I am
VERY
> concerned that it's gonna be holding up Apache 2.0. Apache 2.0 is VERY VERY
> late now...
Amen! You're preaching to the choir, in my case...
> A number of my co-workers are switching to other servers because
> apache just can't handle the load any more. :( With 2.0, I THINK that it
> could but it's not out, so we can't find out.
I suspect we'll have a threaded mpm ready for prime time in a week or
so. I don't know about mod_perl.
> (And if ANYONE suggests that we
> put the current apache 2.0 out onto a production server, they ought to be
> shot. :))
Well, I agreed with you up to this point. You're going to have to shoot
me, I'm afraid, since I put Apache 2.0 up into production on apache.org
(with a lot of help from other folks on this list).
Oh, waitaminute, you said "if ANYONE suggests that WE put..." Whew, I'm
still safe :-) I didn't suggest that YOU put it up yet, without
mod_perl and a threaded mpm :-)
Well, I was under the impression that Apache 2.0 was still VERY unstable over
all of the MPMs. With the prefork MPM seeming to be stable... Hmm... I have
to wonder though if the threaded MPM will cut down on memory. I'll be VERY
curious to look at that... One thing in the back of my mind to do is setup an
apache + SOAP server and see if I can use SOAP with PHP/mod_perl and cut down
on memory... I just haven't had a chance to play with it yet...
>
> So please, let's get 2.0 stable and out the door...
>
> --
> Jeff (FurBall)
Yessir!
Greg
--
Jeff (FurBall)
WebOverdrive Newbie Tech Board
http://www.topniche.com/tech/
furball@weboverdrive.com
Re: What Apache admins want (Was: mod_include performance numbers)
Posted by Bill Stoddard <bi...@wstoddard.com>.
Good stuff, Thanks!
Bill
> Hello,
>
> Just wanted to add to Jeff's comments about what folks running Apache want.
> Here's some background.
>
> I work at Tellme--we run a consumer voice portal (1-800-555-TELL) and also
> host voice services for enterprise customers. Our ENTIRE INFRASTRUCTURE is
> HTTP based. When a user calls into our service, they instantiate a virtual
> voice browser which fetches VoiceXML code from HTTP/HTTPS. All of our data
> feeds, etc. are exposed as XML over HTTP. This gives us tremendous
> flexibility to interoperate with almost any system.
>
> Internally, we use Apache almost exclusively. We have lots of mod_perl
> applications running and also some JSPs; some of our older or less
> commonly used stuff is written as CGIs. I'm the Apache guy at Tellme; I
> develop code, but also maintain lots of Apache servers.
>
> We use Apache because it is stable, configurable, interoperates with so
> many application server technologies, and because it is widely used, well
> understood, and open source.
>
> We aggressively cache stuff, so the speed isn't as big of an issue for us.
> Our biggest concern by far is stability. We are aiming at 99.999% uptime,
> and as our entire service is based on HTTP, the servers are clearly an
> important piece of the puzzle.
>
> Now for static VoiceXML and audio files, Apache is rock solid for
> stability. In the dynamic arena, things are more complicated (there are
> mod_perl and JSP engines to deal with, and SSL is a big headache of
> itself), but Apache itself has never introduced a complication of its own
> (the 3-second CGI delay bug notwithstanding, but we're willing to forgive
> CGI bugs since we don't rely on them for performant stuff).
>
> So, the number one thing we want out of a webserver is that out of the
> box, serving static files, it never crashes or burps. The second thing we
> require from a webserver is that it can be hooked up immediately to
> different application serving technologies--mod_perl or various JSP
> engines for example.
>
> Configurability is also a requirement, but I'm almost 100% sure I don't
> need to tell Apache authors that. :)
>
> Finally, of course, it's a requirement that performance and scalability
> must be "good enough." Apache doesn't need to be as fast or scalable as as
> Zeus webserver, just pretty fast and scalable in its own right. In many of
> our particular situations we just buy more boxes and chuck 'em behind fast
> load balancers instead of relying on monolithic huge servers.
>
> Just another report "from the trenches." Sorry if it distracts from the
> (highly interesting) code-update discussions. Feel free to reply
> personally rather than to the list if this is OT.
>
> Humbly,
>
> Andrew
>
> ----------------------------------------------------------------------
> Andrew Ho http://www.tellme.com/ andrew@tellme.com
> Engineer info@tellme.com Voice 650-930-9062
> Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
> ----------------------------------------------------------------------
>
What Apache admins want (Was: mod_include performance numbers)
Posted by Andrew Ho <an...@tellme.com>.
Hello,
Just wanted to add to Jeff's comments about what folks running Apache want.
Here's some background.
I work at Tellme--we run a consumer voice portal (1-800-555-TELL) and also
host voice services for enterprise customers. Our ENTIRE INFRASTRUCTURE is
HTTP based. When a user calls into our service, they instantiate a virtual
voice browser which fetches VoiceXML code from HTTP/HTTPS. All of our data
feeds, etc. are exposed as XML over HTTP. This gives us tremendous
flexibility to interoperate with almost any system.
Internally, we use Apache almost exclusively. We have lots of mod_perl
applications running and also some JSPs; some of our older or less
commonly used stuff is written as CGIs. I'm the Apache guy at Tellme; I
develop code, but also maintain lots of Apache servers.
We use Apache because it is stable, configurable, interoperates with so
many application server technologies, and because it is widely used, well
understood, and open source.
We aggressively cache stuff, so the speed isn't as big of an issue for us.
Our biggest concern by far is stability. We are aiming at 99.999% uptime,
and as our entire service is based on HTTP, the servers are clearly an
important piece of the puzzle.
Now for static VoiceXML and audio files, Apache is rock solid for
stability. In the dynamic arena, things are more complicated (there are
mod_perl and JSP engines to deal with, and SSL is a big headache of
itself), but Apache itself has never introduced a complication of its own
(the 3-second CGI delay bug notwithstanding, but we're willing to forgive
CGI bugs since we don't rely on them for performant stuff).
So, the number one thing we want out of a webserver is that out of the
box, serving static files, it never crashes or burps. The second thing we
require from a webserver is that it can be hooked up immediately to
different application serving technologies--mod_perl or various JSP
engines for example.
Configurability is also a requirement, but I'm almost 100% sure I don't
need to tell Apache authors that. :)
Finally, of course, it's a requirement that performance and scalability
must be "good enough." Apache doesn't need to be as fast or scalable as as
Zeus webserver, just pretty fast and scalable in its own right. In many of
our particular situations we just buy more boxes and chuck 'em behind fast
load balancers instead of relying on monolithic huge servers.
Just another report "from the trenches." Sorry if it distracts from the
(highly interesting) code-update discussions. Feel free to reply
personally rather than to the list if this is OT.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: mod_include performance numbers
Posted by Greg Ames <gr...@remulak.net>.
"Jeffrey A. Stuart" wrote:
>
> I'd like to amen that... I'm starting to see something here that's concerning
> me. I think that some of the developers have lost touch with what we as web
> admins need.
Welcome aboard, Jeff! I hope we can convince you that we're not all out
of touch.
> We need a server that does following (in order I think.) (and
> all of this of course is IMHO):
>
> 1) A stable server
We've had apache.org running very well on Apache 2.0 for about a month
and a half now, with only two core dumps. Before that, we were on 2.0
since about Feb 15 but it was dumping so frequently
that I wouldn't call it stable. This is with the prefork mpm - the
threaded mpm's have "issues" still ;-)
> 2) One that isn't too memory intensive out of the box.
> 3) One that is fast.
> 4) One that lets us use SSI. (LOTS AND LOTS of sites use SSI...)
> 5) One that lets us tune our heavy/light weight servers better. (One of the
> things that I've been waiting for is Apache 2.0 and mod_perl 2.0.
You got me there...mod_perl isn't ready yet AFAIK.
> With
> Apache's threaded MPM, this LOOKS like we can really tune apache such that our
> mod_perl procs won't be SOO big... And with some of the stuff that was talked
> about with mod_perl 2.0, it looks like we'll really be able to cut some more
> of the memory out.)
> 6) One that all it basically does is serve web pages. I do NOT need another
> email server, another proxy server, another FTP server, another you name it...
> ;)
I hear you...it doesn't make sense to me either.
But I don't mind some of Apache's code being used in a separate
one-server-fits-all project. I just won't choose to spend any time
working on it myself.
>
> First, the part about making apache a multi-proto server while nice, I am VERY
> concerned that it's gonna be holding up Apache 2.0. Apache 2.0 is VERY VERY
> late now...
Amen! You're preaching to the choir, in my case...
> A number of my co-workers are switching to other servers because
> apache just can't handle the load any more. :( With 2.0, I THINK that it
> could but it's not out, so we can't find out.
I suspect we'll have a threaded mpm ready for prime time in a week or
so. I don't know about mod_perl.
> (And if ANYONE suggests that we
> put the current apache 2.0 out onto a production server, they ought to be
> shot. :))
Well, I agreed with you up to this point. You're going to have to shoot
me, I'm afraid, since I put Apache 2.0 up into production on apache.org
(with a lot of help from other folks on this list).
Oh, waitaminute, you said "if ANYONE suggests that WE put..." Whew, I'm
still safe :-) I didn't suggest that YOU put it up yet, without
mod_perl and a threaded mpm :-)
>
> So please, let's get 2.0 stable and out the door...
>
> --
> Jeff (FurBall)
Yessir!
Greg
Re: mod_include performance numbers
Posted by David Reid <dr...@jetnet.co.uk>.
> I'd like to amen that... I'm starting to see something here that's
concerning
> me. I think that some of the developers have lost touch with what we as
web
> admins need. We need a server that does following (in order I think.)
(and
> all of this of course is IMHO):
>
> 1) A stable server
We're getting there on this one...
> 2) One that isn't too memory intensive out of the box.
> 3) One that is fast.
Hmm, we need to do more work on this.
> 4) One that lets us use SSI. (LOTS AND LOTS of sites use SSI...)
> 5) One that lets us tune our heavy/light weight servers better. (One of
the
> things that I've been waiting for is Apache 2.0 and mod_perl 2.0. With
> Apache's threaded MPM, this LOOKS like we can really tune apache such that
our
> mod_perl procs won't be SOO big... And with some of the stuff that was
talked
> about with mod_perl 2.0, it looks like we'll really be able to cut some
more
> of the memory out.)
Threaded MPM's may help...
> 6) One that all it basically does is serve web pages. I do NOT need
another
> email server, another proxy server, another FTP server, another you name
it...
> ;)
Yeah, I know, I know.
>
> First, the part about making apache a multi-proto server while nice, I am
VERY
> concerned that it's gonna be holding up Apache 2.0. Apache 2.0 is VERY
VERY
> late now... A number of my co-workers are switching to other servers
because
> apache just can't handle the load any more. :( With 2.0, I THINK that it
> could but it's not out, so we can't find out. (And if ANYONE suggests
that we
> put the current apache 2.0 out onto a production server, they ought to be
> shot. :))
There are a number of us who feel like this, but there are a number of
people who also have a counter view point. It's a shame, but there it is.
>
> So please, let's get 2.0 stable and out the door...
Nice to have some more view points. Anyone else care to drop a dime?
david
RE: mod_include performance numbers
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 21 Apr 2001, Jeffrey A. Stuart wrote:
> I'd like to amen that... I'm starting to see something here that's concerning
> me. I think that some of the developers have lost touch with what we as web
> admins need. We need a server that does following (in order I think.) (and
> all of this of course is IMHO):
Note that part of the issue is that there are a lot more different "we"s
around now than there were a few years ago, and a lot more conflicting
demands.
But, the reality is, that people contributing to Apache control where it
goes. And it just so happens that we don't have any active committers
(that I can think of just now... am probably missing a few) that are
focused on getting Apache 2.x to a place where it is usable on their own
high traffic, production web servers. And there is only so much that can
be done to make that happen without people who need it stepping in and
helping out. I think it would be great to have a job where I was involved
in trying to get Apache 2.x to a state where it could be deployed on my
employer's high traffic site... but the reality is that isn't the way
things are done at most companies any more.
A large percent of current development is done by people employed by
companies that produce Apache based products. It is great they are
contributing, but it definitely does result in a slightly different
perspective. I dunno if anything can/should be done.
(easy for me to ramble, as I sit here trying to figure out if I want to
get more involved in Apache again and, if so, how I can deal with finding
a job in Seattle that lets me do so... sigh)
RE: mod_include performance numbers
Posted by "Jeffrey A. Stuart" <js...@neo.rr.com>.
I'd like to amen that... I'm starting to see something here that's concerning
me. I think that some of the developers have lost touch with what we as web
admins need. We need a server that does following (in order I think.) (and
all of this of course is IMHO):
1) A stable server
2) One that isn't too memory intensive out of the box.
3) One that is fast.
4) One that lets us use SSI. (LOTS AND LOTS of sites use SSI...)
5) One that lets us tune our heavy/light weight servers better. (One of the
things that I've been waiting for is Apache 2.0 and mod_perl 2.0. With
Apache's threaded MPM, this LOOKS like we can really tune apache such that our
mod_perl procs won't be SOO big... And with some of the stuff that was talked
about with mod_perl 2.0, it looks like we'll really be able to cut some more
of the memory out.)
6) One that all it basically does is serve web pages. I do NOT need another
email server, another proxy server, another FTP server, another you name it...
;)
First, the part about making apache a multi-proto server while nice, I am VERY
concerned that it's gonna be holding up Apache 2.0. Apache 2.0 is VERY VERY
late now... A number of my co-workers are switching to other servers because
apache just can't handle the load any more. :( With 2.0, I THINK that it
could but it's not out, so we can't find out. (And if ANYONE suggests that we
put the current apache 2.0 out onto a production server, they ought to be
shot. :))
So please, let's get 2.0 stable and out the door...
--
Jeff (FurBall)
WebOverdrive Newbie Tech Board
http://www.topniche.com/tech/
furball@weboverdrive.com
-----Original Message-----
From: Marc Slemko [mailto:marcs@znep.com]
Sent: Friday, April 20, 2001 6:09 PM
To: new-httpd@apache.org
Subject: Re: mod_include performance numbers
On Fri, 20 Apr 2001, Paul J. Reder wrote:
> Ian Holsman wrote:
> > I'm not sure if this means that ALL filters are slow, or if
> > it is just mod-include.
>
> I'm sure that there are some aspects of mod_include that can be improved,
> but the fact of the matter is that a filter that looks at every byte across
> buckets and brigades is going to slow things down. With 2.0 admins will
> need to do a more judicious job of bringing filters into play (like not
> running all .html and .shtml files through mod_include).
Umh... that's bogus. There is no reason and no way that simply having a
file parsed for SSIs should have to be that slow. I hope there is
something very not right here (ie. room for big performance improvements)
causing very poor results, but SSIs have always been quite cheap to parse
(despite what people like saying; traditionally, any overhead has been
more in the loss of cachability), and it seems pretty weak to take such a
massive performance hit. What mod_include is doing is quite simple, and
running some simple pattern matching over the output just shouldn't be all
that expensive when the CPU cycles required should be so cheap.
Lots of sites base lots of stuff on using a bunch of includes. I just
want to point out that saying "well, admins will just have to use less
includes" is not any sort of answer.
Re: mod_include performance numbers
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 20 Apr 2001, Paul J. Reder wrote:
> Ian Holsman wrote:
> > I'm not sure if this means that ALL filters are slow, or if
> > it is just mod-include.
>
> I'm sure that there are some aspects of mod_include that can be improved,
> but the fact of the matter is that a filter that looks at every byte across
> buckets and brigades is going to slow things down. With 2.0 admins will
> need to do a more judicious job of bringing filters into play (like not
> running all .html and .shtml files through mod_include).
Umh... that's bogus. There is no reason and no way that simply having a
file parsed for SSIs should have to be that slow. I hope there is
something very not right here (ie. room for big performance improvements)
causing very poor results, but SSIs have always been quite cheap to parse
(despite what people like saying; traditionally, any overhead has been
more in the loss of cachability), and it seems pretty weak to take such a
massive performance hit. What mod_include is doing is quite simple, and
running some simple pattern matching over the output just shouldn't be all
that expensive when the CPU cycles required should be so cheap.
Lots of sites base lots of stuff on using a bunch of includes. I just
want to point out that saying "well, admins will just have to use less
includes" is not any sort of answer.
Re: mod_include performance numbers
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Ian Holsman wrote:
> I'm not sure if this means that ALL filters are slow, or if
> it is just mod-include.
I'm sure that there are some aspects of mod_include that can be improved,
but the fact of the matter is that a filter that looks at every byte across
buckets and brigades is going to slow things down. With 2.0 admins will
need to do a more judicious job of bringing filters into play (like not
running all .html and .shtml files through mod_include).
>
> I also have some truss output for these, and I'll put them on the site
> if anyone wants to see what is going on.
I would love to see any performance or profiling information that you have.
The more info, the better the solution.
Thanks,
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein