S3Sync.net

Hello:

I've done some performance testing on s3sync and s3cmd. The quick summary is that relative to wget the s3sync and s3cmd "get" operations are about 5 times slower. The get operations spend about 40% of their time in userspace code which, to me, may indicate a hot spot caused by a possibly inefficient procedure.

"put" operations seem about the same speed as wget "get" operations so I didn't do additional testing on "puts".

My data:

http://spreadsheets.google.com/pub?key=pQFDXIemKG2G5YG2T-_T1eg

All testing was done between EC2 and S3 so network performance should be optimal. Files were erased between runs to ensure that the results reflected network performance and not hash matches.

Let me know if you have more questions or need other data. Maybe if I can figure out how to profile ruby code I can lend some advice or a patch.

Brad

Ruby comes with tracing and debugging available, though I haven't used it too much myself.

It would certainly be helpful if we found a way to get performance boosted substantially!  I find it equally likely that the problem is within the Ruby library code somewhere, but if we can learn where we might still be able to patch around the inefficiency.

It could also be something such as the default read/write chunk size might be too small.

when I GET with the ruby lib stuff set up to stream I get up to about 700KB/s, the same maximum that my ISP's speed test shows.  I watched the process while downloading a 22M test file (this is on linux).  the only time the ruby process even registered 1% of the cpu was the last second or so when calculating the etag check (which I do after the download finishes).  altogether this makes me think the ruby libraries, certainly on linux, are not likely to be the problem area.

you should be able to run the ruby profiler by
    ruby -r profile s3sync ...

notice I didn't mention PUTs?  that's because my DSL connection limits them to around 40KB/s.  for what it's worth the cpu consumption never is even visible except for when calculating the etag, but this speed is so low as to hardly be a challenge.

during the GETs the segments I'm getting back are usually 1024 or 436 bytes, but they can be other lengths.  don't ask me why, I don't control it.

for what it's worth, here is the profiler output from a GET of a 22M file (I removed any calls below 1%).  remember, during a normal run without the profiler, the cpu never gets above 1% except calculating the etag, my guess is because the ruby lib just calls down to the socket library which uses hardly any cpu.  you can see the call that generates the etag down near the bottom.

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 17.33    14.13     14.13    21662     0.65     0.93  Thread#kill
 15.43    26.71     12.58    21664     0.58     1.76  Timeout.timeout
 14.19    38.28     11.57        1 11570.00 76470.00  Net::BufferedIO#read
  7.28    44.22      5.94    21661     0.27     0.39  Net::ReadAdapter#call_block
  4.84    48.17      3.95    21664     0.18     1.95  Object#timeout
  4.52    51.86      3.69    21687     0.17     0.26  Net::BufferedIO#rbuf_consume
  4.14    55.24      3.38    21662     0.16     0.16  Thread#start
  3.00    57.69      2.45        5   490.00 16106.00  IO#open
  2.53    59.75      2.06    21661     0.10     0.49  Net::ReadAdapter#<<
  2.43    61.73      1.98    21662     0.09     2.04  Net::BufferedIO#rbuf_fill
  2.32    63.62      1.89    21687     0.09     0.09  String#slice!
  2.29    65.49      1.87    21682     0.09     0.09  String#<<
  2.16    67.25      1.76    21661     0.08     0.08  Fixnum#<
  2.10    68.96      1.71    21661     0.08     0.12  IO#<<
  1.99    70.58      1.62    65010     0.02     0.02  String#size
  1.85    72.09      1.51    21676     0.07     0.10  Fixnum#==
  1.55    73.35      1.26    43469     0.03     0.03  Fixnum#+
  1.25    74.37      1.02    21662     0.05     0.05  IO#sysread
  1.16    75.32      0.95    21660     0.04     0.04  Digest::Base#<<
  1.13    76.24      0.92    21662     0.04     0.04  Kernel.sleep
  1.04    77.09      0.85    21665     0.04     0.04  IO#write

I don't see anything in those results that point to s3sync doing dumb looping or etc.

However both for you and for lfh's results (he is not using my software), the Thread#kill and Timeout.timeout seem to be taking over 30% of the time if I'm reading it right.

What I'm not sure of, is whether these results aggregate inner calls to the other inner functions, or whether the time is spent *just* and *only* executing code native to that function.

I would assume the former, which means this result isn't all that informative.  For example it might be spending time in "timeout" waiting for the network result to come back, etc.

I am *not* an expert in ruby by any stretch, so I'm probably not the most qualified to pursue these details.

oh boy, I just love it when my login times out while writing a post...

here is a test we haven't tried: cut ruby out of the loop by downloading the same file using your browser.  there is a bit of fuzz because I have to click "save to disk" with firefox, but my time to download the link below is pretty much exactly the same as using ruby (30 seconds), which says neither my code nor the ruby libraries are likely to be doing anything stupid.

http://s3.amazonaws.com/1001/zero.bin

the file contains exactly 20,000,000 bytes and you should be able to download it for your own testing.

I did use a web browser as a control for the get operation. Take a look at my original data. The "wget" data uses the command line wget agent to fetch the same objects via HTTP. wget is about 6-7x faster than "s3cmd get".

Brad

bdixon:  yes, I'm blind ;-).

greg: what happens when you do this?  I tried wget with the file above, and my times in ruby and wget are less than 1 second different (~29.5sec), well within the noise.  I could understand a bit of overhead, e.g. I do a HEAD call that wget doesn't and I do an extra etag check, but 6x-7x is way out of line.  platform may matter, I'm on fedora core 6, x86.

I haven't tested that.  I think it's clear from the above that 1) it's something in ruby but 2) not in my code per se, and 3) it doesn't happen for everyone.

not quite, from *my* tests it is clear that it is *nothing* in ruby, since ruby and wget take the same time.

however brad didn't say what platform he's running on.  you (greg) are on windows, right?  why don't you take a minute, click my link earlier, and find out how long your browser takes to get the file (I assume you don't have wget, although you could get it from http://www.christopherlewis.com/WGet/WGetFiles.htm) vs how long it takes to get it with s3sync?

brad: platform?

all right all right.. it *is* the weekend, I suppose this counts as recreation ye?

wget times are mostly within 43-45s
s3cmd are mostly within 46-48s

This is on Windows.  When I profile ruby here, it REALLY sucks the performance down though.. So instead I just clock timed it.

right, the time when running the profiler is meaningless.  the profiler slows things down enough by itself that it could mask other issues, e.g. disk or network waits.  still, the profiler gives the raw counts which can be quite useful.

were you testing by grabbing the 20M link I provided?  if yes, then you are taking 50% or so more time than I do to get it.  my DSL connection is the bottleneck as far as I can tell, i.e. my download speed seems to be about the same no matter what tool I use.

brad:  what OS are you running?

Yes I was testing with your file lfh.

The total time to get it is not of interest.. It just reflects my maximum available bandwidth to my home windows machine here.  In addition to having a cheap connection, I am also running freenet, which is a nearly constant drain on part of my available width.

of course total time *would* be of interest if it didn't match up pretty well with available bandwidth ;-).

Only if there was a noticeable difference from wget (which is accepted as the control in our tests)

I was running this on the Amazon provided Fedora Core 4 image. I hacked it up a little but not tons.


# uname -a
Linux domU-12-31-34-00-02-27 2.6.16-xenU #1 SMP Thu Oct 26 08:41:26 SAST 2006 i686 athlon i386 GNU/Linux
# ruby -v
ruby 1.8.4 (2005-12-24) [i386-linux]

I think all my ruby's are 1.8.5.  It's possible that they sped it up?

mine are 1.8.5 also.  it's possible there were fixes in the http lib, although it is hard to imagine what would affect what is basically a loop writing into a socket.

Has the download speed issue been solved? I got the following results using s3sync from an EC2 instance. I am using FC6 with ruby version 1.8.5.

22MB file using s3cmd
Upload - EC2 => S3  = 6 MB/s
Download - S3 => EC2  = 1.4 MB/s

22MB file using WGET
Download S3 => EC2 = 11MB/s

I can live with the upload speed of 6MB/s. However, the download speed is pretty slow. Has anyone found a better way to go about this?

We haven't been able to repro the slowness, so there's nothing "solved" per se.