httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <>
Subject Re: mod_include performance numbers
Date Fri, 20 Apr 2001 22:30:32 GMT
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

View raw message