httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof ...@organic.com>
Subject Re: ack re: [PATCH] performance improvement
Date Sun, 02 Feb 1997 04:31:50 GMT
I'm not too surprised about the minimal improvements from changing the
tests.  Really, we need a better method to parse the file...

I don't know the frequency with which GET_CHAR is used in different
sections, but find_string does seem to be the most likely resource hog.

Could you send your whole patch?  Ugly doesn't bother me too much, since
I'd expect primary development to shift from this code base to something
new (for Apache 2.0) once we finish 1.2.  Besides, what's there now is
pretty ugly & somewhat inefficient...

     -- Ed Korthof        |  Web Server Engineer --
     -- ed@organic.com    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --

On Sat, 1 Feb 1997, Marc Slemko wrote:

> On Fri, 31 Jan 1997, Ed Korthof wrote:
> 
> > On Jan 31,  9:58pm, Rob Hartill wrote:
> > > > Yes, I realized that. <blush> Well, without that, the patch appears
to
> > > > work fine --
> > >
> > > did you measure any performance gain ?. Every little helps. Was it too
> > > little to notice though ?
> > 
> > Not yet -- I'll try this weekend or early next week.  We'll also be switching
> > to the most recent beta, and will see if that leads to any performance
> > improvements (I'll have a good idea if there was a net performance gain, but
> > it'll be hard to identify which components contributed).
> 
> I hacked GET_CHAR in mod_include to have its own buffer and pull in data
> in chunks of 5000 bytes; ie. return a byte from the buffer if the buffer
> isn't empty, get more if it is.  This resulted in a very minimal
> performance improvement.  The removal of the feof and ferror checks had a
> similarily trivial improvement.  A large file (2-15 megs in size) with no
> parsing expansions in it still gets sent at ~1/3rd the speed of a
> non-parsed file, regardless of which of the above I tried.  I don't think
> input buffering is the biggest problem, at least on FreeBSD.
> 
> By adding a rputc define to mod_include that did simple output buffering
> in blocks of 5000 bytes (well, 1k blocks did around the same thing) and
> then calling rwrite I was able to boost the speed so it was 2/3rds
> the speed, again with no actual directives being parsed.  This
> requires several other modifications to work properly.  For one,
> all output needs to use the same buffering or things (the few things
> that aren't sent with rputc) will get put in the wrong order.  The
> second thing is that it needs to flush the buffer before exit.
> Neither are overly complicated.
> 
> My hack to mod_include to simple output buffering:
> 
> #define rputc(c,r) \
>  { \
>   if (buffered == 5000) { rwrite(outbuf, 5000, r); buffered = 0;  } \
>   outbuf[buffered++] = c; \
> }
> 
> ...with buffered and outbuf being global variables.
> 
> Comments?  Ugly, but...
> 


Mime
View raw message