From: pat eyler <pat.eyler@...>
Date: 2005-11-24T21:48:00+09:00
Subject: Re: [ANN] RWB 0.2.0 (now with extra RubyForge goodness)

On 11/23/05, Wilson Bilkovich <wilsonb@gmail.com> wrote:
> I took a brief look at the code a week or so ago, and I like it.
> However (and this might just be my lack of deep understanding of the
> way Ruby deals with sockets), it seems to me that the 'concurrency'
> feature doesn't really do much.

Concurrency may be too strong a word, but I'm not sure what else
to call it.  So far RWB has worked well enough for me, but I'd be
happy to work with people who find it's not up to their tasks.   My
big aims to this point are to get a working request engine and a
nice, featureful reporting system.

> Isn't the bulk of the work performed in the concurrent threads being
> serialized by the host process?  When I look at the timestamps on the
> web server, the requests seem to arrive more or less in order.
> Am I using a crappy web server log, or is this really how it behaves
> in the absence of native threads?  I'm probably just expecting
> parallelism, and getting concurrency instead.

Unless someone wants to point out an improvement in my thread
handling, I think that wysiwyg applies.

> I slapped together a lame little script that starts 100 instances of
> the Ruby interpreter, and that managed to actually make numerous
> requests arrive simultaneously at the server.  Unfortunately, it used
> a truly shocking amount of memory on the client system.

Wow, I'll bet that was huge.  I'd be interested in seeing what
native threads do for performance.  Could you share your results?

>
> Stated another way; how different are:
> tests = RWB::Runner.new(urls, 1000, 5)
> and:
> tests = RWB::Runner.new(urls, 1000, 1000)
> ?

The big difference is going to be against a slower webserver
(or against slower dynamic pages).   In that case the second
invocation will spawn 1000 threads without weighting for any
of them to finish, while the first will end up waiting at least
some of the time.  (At work I've had a couple of requests go
in excess of 3 seconds, so I can really see the difference
with higher levels of (pseudo) concurrancy.

The other difference you'll see (even on a fast site) is in load
generation/testing.  Here are two runs for comparison:

Concurrency Level:       5
Total Requests:          1000
Total time for testing:  16.329556 secs
Requests per second:     61.2386521715594
Mean time per request:   81  msecs
Standard deviation:      77
Overall results:
        Shortest time:  48 msecs
        25.0%ile time:  56 msecs
        50.0%ile time:  57 msecs
        75.0%ile time:  59 msecs
        Longest time:   703 msecs


Concurrency Level:       1000
Total Requests:          1000
Total time for testing:  8.444824 secs
Requests per second:     118.415730156129
Mean time per request:   84  msecs
Standard deviation:      186
Overall results:
        Shortest time:  21 msecs
        25.0%ile time:  26 msecs
        50.0%ile time:  34 msecs
        75.0%ile time:  37 msecs
        Longest time:   1103 msecs

You can see that we were able to throw almost
twice as many requests per second against the
server this way, which can be an important measure
when you're talking about how to scale/optimize
a website for a large traffic load.

>
> Thanks for reading my incoherent babble.

Thanks for sharing.

> --Wilson.
>



--
thanks,
-pate
-------------------------