httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: 2.0 performance Re: Breaking something? Now is the time?
Date Fri, 28 Jun 2002 21:47:46 GMT
Bill Stoddard wrote:
...

>mod_mem_cache bypasses most all of those things. Using mod_mem_cache to
>cache a buffer in heap (contents of a 500 byte file).  I have even hack the
>code slightly to turn off the pipelined request optimization. I am playing
>with a new tool so I don't fully grok the output just yet but here is what I
>see serving a single keep alive request out of mod_mem_cache.
>

Thanks for the profile data!

> The divisions are
>real killers (at least on this machine). Suggests that we need a call,
>apr_time_now_sec() to fetch the time with seconds resolution (configurable).
>Now we do multiplications to convert to uS then do divisions to convert back
>to seconds in a number of routines.
>

I've seen the rem and div code taking a long time in 32-bit mode
on Sparcs, too.  At last count, we have at least three proposed
solutions: a new API that returns seconds, converting the 64-bit
int to a struct with separate seconds and usec, and Will Rowe's
binary microseconds proposal.  Any of them would be an improvement.
I'll add a call for votes on these to APR's STATUS file.

>The time spent in ap_brigade_puts is
>suprising...  This particular run indicate that it tool 74355 instructions
>to serve a keep alive request.
>

I've seen the brigade_puts overhead in my testing, too...and it
is definitely surprising, since the code is relatively minimal.
The only obvious (potential) speedup I can think of would be to
replace the char-at-a-time loop with a memcpy (with checks to
make sure it doesn't overflow the available size).  I'll try this
over the weekend.

--Brian



Mime
View raw message