Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion RFuzz 0.7 -- Win32, Bug Fix, Browser Begins
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Alex Young  
View profile  
 More options Aug 6 2006, 2:37 am
From: Alex Young <a...@blackkettle.org>
Date: Sun, 6 Aug 2006 15:37:33 +0900
Local: Sun, Aug 6 2006 2:37 am
Subject: Re: [ANN] RFuzz 0.7 -- Win32, Bug Fix, Browser Begins

Zed Shaw wrote:
> On Sat, 2006-08-05 at 16:07 +0900, Alex Young wrote:

>>Zed Shaw wrote:

>>In case anybody's wondering...

> <snip>

>>Rehearsal -------------------------------------------------------
>>net/http              7.720000   1.470000   9.190000 (  9.195841)
>>rfuzz                 3.040000   1.070000   4.110000 (  4.119992)
>>--------------------------------------------- total: 13.300000sec

>>                           user     system      total        real
>>net/http              7.930000   1.370000   9.300000 (  9.298725)
>>rfuzz                 2.950000   1.130000   4.080000 (  4.073578)

> Yeah it should be faster just by virtue of having very little to it and
> using a C parser.  Keep in mind that rfuzz--unlike mongrel--isn't really
> designed for speed but more for letting you easily hit web servers with
> any kind of request.  Another thing some folks don't notice is that all
> of the HttpClient requests are "data driven".  That means you can power
> RFuzz blindly from a YAML file full of strings and hashes.

> Otherwise net/http has a bunch more features, but I'll slowly add them
> as I need them.  I think SSL is next on the list.

>>That doesn't include those speedups for net/http that went through the
>>list a couple of weeks back, though.

> I'd also be curious for the same test run with the RFuzz call being done
> inside a Timeout block.  RFuzz doesn't do any of that (bare metal), and
> I know Timeout blocks fire up an extra thread and eat up a bit more CPU.
> I'm betting that putting RFuzz inside Timeout makes it about the same
> speed at net/http.

Not quite:

alex@pandora:~/Desktop/Noodling/ruby$ cat rfuzz_test.rb; ruby rfuzz_test.rb
require 'mongrel'
require 'rfuzz/client'
require 'net/http'
require 'benchmark'
require 'timeout'

m = Mongrel::HttpServer.new('0.0.0.0', '8080')
m.register('/', Mongrel::DirHandler.new('.'))
m.run

def do_download(h, path)
   h.get(path)
end

def do_timeout_download(h, path)
   timeout(30){
     h.get(path)
   }
end

n = 1000

Benchmark.bmbm(20) do |b|
   u = URI.parse('http://localhost:8080/rfuzz_test.rb')
   h = Net::HTTP.new(u.host, u.port)
   b.report('net/http'){ for i in 0..n; do_download(h, u.path); end }
   r = RFuzz::HttpClient.new(u.host, u.port)
   b.report('rfuzz'){ for i in 0..n; do_download(r, u.path); end }
   b.report('rfuzz+timeout'){
     for i in 0..n; do_timeout_download(r, u.path); end }
end
Rehearsal -------------------------------------------------------
net/http              8.000000   1.380000   9.380000 (  9.609907)
rfuzz                 3.110000   1.090000   4.200000 (  4.213084)
rfuzz+timeout         3.660000   1.270000   4.930000 (  4.933268)
--------------------------------------------- total: 18.510000sec

                           user     system      total        real
net/http              8.060000   1.480000   9.540000 (  9.620967)
rfuzz                 3.090000   1.090000   4.180000 (  5.725728)
rfuzz+timeout         3.680000   1.230000   4.910000 (  4.991043)

But then again, that's not what Net::HTTP's actually doing - it puts a
timeout around every single rbuf_fill call, so by default it has to
spawn a new thread for every 1K of data it intends to receive.  I'm sure
there's a damn good reason for that, but it's a reason I don't think I'd
have spotted if I was writing it. That shouldn't be a problem on this
test, though - the file it's downloading is only 715 bytes.  I'll try
the test with a bigger file and see what I can see.

--
Alex


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google