[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