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" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg Ames <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]><[EMAIL PROTECTED]>
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
> http://8ball.federated.com/ 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
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
