httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject [Fwd: Re: Performance numbers..... ;(]
Date Fri, 17 Aug 2001 17:09:44 GMT
Victor meant for this to go to the list...perhaps I should quit
reminding him of his infamous stick remark.

-------- Original Message --------
Subject: Re: Performance numbers..... ;(
Date: Fri, 17 Aug 2001 11:10:24 -0400
From: "Victor J. Orlikowski" <>
To: Greg Ames <>

On Friday, 17 Aug 2001, at 10:18:19,
Greg Ames wrote:
> Victor,
> Now we're going to have to beat you with a stick.  You didn't mention
> what kind of workload you're running.  Are you serving a static file? 
> How big?  These things are important to know when analyzing benchmark
> results.  
Oh great. Now I'm in for it. ;)

> I'm guessing you're serving a smallish static file.  The Magic 8-ball at
> said "Without a doubt" when I asked this
> question.
The 8-ball is correct. Serving a single static file, 500 bytes in size.

> If ssi's were working, and you were measuring them, I think we would see
> 2.0 look a lot worse compared to 1.3, and threaded worst of all, because
> we don't have a fast mutex-free replacement for malloc/free yet <sigh>. 
> For the buckets code, having some kind of connection lifetime apr_pool
> might be good enough, if we had a way to terminate keepalive connections
> that ate too much memory.  But we need a good apr_malloc/free for other
> stuff anyway, like caching.
Wasn't even trying to invoke ssi. I had a feeling that our performance
was sub-optimal there. I was trying to get a basic idea of how fast
the server would handle an extremely simple request.

> I'm thinking it might be worth the effort to have some kind of
> apr_compare_and_swap primitive.  Yes, it would involve writing a little
> assembler code for the different CPU architectures, which Apache hasn't
> done before AFAIK.  But let's say we got past that and had it
> available.  We could use it to create:
> * apr_push/pop, which could be used for memory block allocators
> (apr_pools and apr_malloc),  and
> * apr_atomic_add, which could be used to safely increment and decrement
> shared counters etc.,
> all without mutexes.  
Sounds cool to me. 

> p.s. just kidding about the stick
As expected. Never a good beating when one deserves one. :)

Also, I'll run another test, this time running a syscall trace (to
make Brian Pane and Dean happy) and I'll post that.

Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
================================================================== | |

View raw message