httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: mod_include performance numbers
Date Fri, 20 Apr 2001 22:08:35 GMT
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.


Mime
View raw message