[tahoe-dev] benchmarking

[Thomas Delaet]

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

Thanks for the tips! I'm planning to profile the blackmatch.py stuff
this weekend and try to improve Tahoe's performance before I gather my
final results.

I'll keep you informed

Kind Regards

Thomas