httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject RE: mod_include performance numbers
Date Fri, 20 Apr 2001 22:13:49 GMT
I've put the 'truss' output added as a link to the page.
this was taken from Solaris 2.6 (which is old, but the numbers
should be read as relative)

I am working on getting a '1.3' version of the same thing up, probably
by monday (testing machine is dead)

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

we are planning on doing a LOT of things with mod_include, and SSI
is very central to the design. the ability to split up the file into
multiple parts lets you do some nifty things like co-branding, and
ad insertion relative to the user.

we could always re-implent a non-filtered version of mod_include, but 
that would put us in the situation we are currently in, every change made
goes into mod-include making it unmaintable.

BTW.. I didn't want to start a flame on this issue

View raw message