[tahoe-dev] benchmarking

Zooko Wilcox-O'Hearn zooko at zooko.com
Wed Sep 23 23:16:37 PDT 2009


following-up to my own post:

On Thursday,2009-09-24, at 0:00 , Zooko Wilcox-O'Hearn wrote:

> I'm leery of adding caching to Tahoe-LAFS proper because caching is  
> usually a tradeoff of gaining performance at a cost of correctness,  
> and the apps layered atop Tahoe-LAFS can know better than Tahoe- 
> LAFS can which of those tradeoffs are wins for them.

Oh, and I should also mention because there is still a lot of "low  
hanging fruit" in improving Tahoe-LAFS performance without the  
complications introduced by caching mutable things.

In fact, Tahoe-LAFS used to download files a lot faster -- about two  
*times* as fast over a 100 Mbps LAN, if I recall correctly -- and we  
made the segment size smaller in order to get better alacrity (i.e.  
for there to be a shorter delay between hitting "play" and the movie  
starting) and smoother download rate (to make Firefox 2 stop doing  
http://xkcd.com/612/ ).

So, putting the segment size back to 1 MiB ought to make it much  
faster on upload on a fast network, right?  Except if I recall  
correctly, it didn't make any difference over DSL when I tried it.

Basically, there is probably something really dumb that we are doing  
which costs a large factor of upload/download speed in some cases,  
and as far as I know nobody has really analyzed network traces or  
otherwise figured out what the dumb thing is.  I just created ticket  
#890 for the first step in diagnosing this.

Regards,

Zooko

http://allmydata.org/trac/tahoe/ticket/809 # Measure how segment size  
affects upload/download speed.


More information about the tahoe-dev mailing list