[tahoe-dev] Benchmarks - 1.7.1 vs. 1.8.0c3

[Kyle Markley]

Here's some more data.

I ran two more experiments for comparison, both using the default (3/7/10)
encoding.  For the first, I had 5 storage nodes on the same machine as the
client, and 5 storage nodes on a remote machine (over wireless).  For the
second, I placed all 10 storage nodes on the same machine as the client. 
(I didn't try any configurations with no local storage; maybe later I'll
try that, and try with more machines.)

Results files attached.
default_{171,180c3}.log is the experiment with 5 local and 5 remote
storage nodes.
default_local_{171,180c3}.log is the experiment with 10 local storage
nodes.

In each, the commands are:
1) tahoe backup of large files
2) tahoe backup of small files
3) tahoe cp -r download of large files
4) tahoe cp -r download of small files
5) cleanup (ignore this)

It's clear that 180c3 helps for downloading small files.  It may be a
little worse for downloading large files, at least where network latency is
negligible.  Running with more machines would be more realistic.


I was surprised by the low CPU utilization even when all the nodes were
local.  The storage nodes typically ran about 2-3% utilization and the
client node meandered around 15-30%.  With everything local (and no network
to blame) I expected high utilization.  This machine has 8 threads, so with
11 active processes there was very little contention for processing
resources.  Running everything locally helps a lot for large files, but
interestingly seems to hurt for small files!


To run multiple storage nodes on each machine I had to randomize the
storage nodes' web.port, which makes my script fragile: it could try to use
a port that happened to be in use.  Is there a way to have tahoe pick a
web.port instead of me specifying it?  Or a better idea about what I could
do?



On Sun, 05 Sep 2010 03:05:29 -0400, Kyle Markley <kyle at arbyte.us> wrote:
>> Anyway, if you can compare the performance of v1.8.0c3 to any previous
>> versions of Tahoe-LAFS that you have measured, that would be helpful.
>> v1.8.0c3 is expected to be better-performing than both v1.7.1 and
>> v1.8.0c2 for almost all server/share layouts, and much
>> better-performing for certain layouts.
> 
> I spent some time fixing up my benchmarking script for running a storage
> node on Windows.  (What a mess that was!)  I've attached my latest
scripts
> and the results from large and small file transfers of a 1/1/1
> configuration with a single remote storage node over wireless, on both
> 1.7.1 and 1.8.0c3.
> 
> Unsurprisingly, with a 1/1/1 configuration there's little difference
> between 1.7.1 and 1.8.0c3.  What did surprise me was how much slower
> download is than upload.
> 
> I'll do some more interesting configurations tomorrow.  I'm happy to
take
> requests for configurations, but I only have 4 computers to play with. 
(I
> can run more than one storage node per computer if needed.)

-- 
Kyle Markley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default_171.log
Type: application/octet-stream
Size: 3368 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100905/441c7d7e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default_180c3.log
Type: application/octet-stream
Size: 3525 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100905/441c7d7e/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default_local_171.log
Type: application/octet-stream
Size: 3374 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100905/441c7d7e/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default_local_180c3.log
Type: application/octet-stream
Size: 3532 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100905/441c7d7e/attachment-0003.obj>