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.
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.
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.

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

Thanks for reading my incoherent babble.
--Wilson.


On 11/9/05, pat eyler <pat.eyler / gmail.com> wrote:
> RWB 0.1.1 was released last night, but before I put together an
> announcement, I ended up putting together a 0.2.0 release too.
>
> This combined release features three new warmup methods:
>    warmup(num_runs)
>    rand_warmup(num_requests)
>    spec_warmup(urls, num_runs)
> These methods will exercise your website prior to the recorded tests.
>
> RWB 0.2.0 also adds the Runner#add_proxy method, so RWB will now work
> behind a web proxy.
>
> You can grab your copy from rubyforge.org/projects/rwb/ (a couple
> of examples are hiding at www.red-bean.com/~pate as well).
>
> Don't forget to send me you comments, suggestions, requests, patches,
> etc.