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/
[EMAIL PROTECTED]
-----Original Message-----
From: Marc Slemko [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 6:09 PM
To: [EMAIL PROTECTED]
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.
