>> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
