Poor performance in test grid

Lukas Pirl tahoe-dev at lukas-pirl.de
Wed Dec 25 13:16:44 UTC 2013


Hi Team Tahoe!

I really like the concept of tahoe-lafs so I tried it out.

Sadly, I was really disappointed when I experienced very poor
performance (~1.6 MB/s for reads and writes). I used multiple gateways
(SFTP via gvfs, SFTP via 'sftp' command, CLI) but it was slow in any case.

I would be very happy if someone would share an idea on how to fix this.
I'd love to use tahoe to backup my servers as a lot of Debian backups
could share a lot of files ;)

My setup looks like this:

* Hardware: Atom CPU (D525) @ 1.80GHz, Storage on SSD
* 30GB free disk space, ext4
* 3GB RAM free
* average system load: almost 0
* all servers on the same machine:
  * 3 storage servers
  * 1 introducer (obviously)
  * 1 gateway server

$ tahoe --version:

allmydata-tahoe: 1.10.0
foolscap: 0.6.4
pycryptopp: 0.6.0.1206569328141510525648634803928199668821045408958
zfec: 1.4.24
Twisted: 13.2.0
Nevow: 0.10.0
zope.interface: unknown
python: 2.7.6
platform: Linux-debian_jessie/sid-x86_64-64bit_ELF
pyOpenSSL: 0.13.1
simplejson: 3.3.1
pycrypto: 2.6.1
pyasn1: 0.1.7
mock: 1.0.1
setuptools: 2.0

$ grep shares tahoes/gw/tahoe.cfg
shares.needed = 3
shares.happy = 2
shares.total = 10

I experienced the same issue on a similar machine with a Core 2 Duo @
2.6GHz.

I observed that while uploading, the gateway ate up 1 core completely.
After all data had been transferred (ex: Nautilus copy progress @
100%), the gateway and 2 storage servers ate up one core each for
quite a while (almost the same time it took to upload the file). After
that, the file-system call returned (ie. Nautilus closed the copy
dialog hat was stuck at 100%).

Uploading via network (20MB/sek) or on the same machine made almost no
difference.

Thanks in advance & happy Xmas!

Lukas
-- 
+49 174 940 74 71


More information about the tahoe-dev mailing list