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 [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 20, 2001 3: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.
>
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
