tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

add another set of load-testing results, with 1MB mean file size 

[Imported from Trac: page Performance, version 22]
warner 2007-12-19 02:12:45 +00:00
parent d191d4b47c
commit 352eecc195
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
Performance.md

@ -133,6 +133,8 @@ The source:src/allmydata/test/check_load.py tool can be used to generate
random upload/download traffic, to see how much load a Tahoe grid imposes on
its hosts.
### test one: 10kB mean file size
Preliminary results on the Allmydata test grid (14 storage servers spread
across four machines (each a 3ishGHz P4), two web servers): we used three
check_load.py clients running with 100ms delay between requests, an
@ -158,6 +160,23 @@ averaging 60%-80% CPU usage. Memory consumption is minor, 37MB [VmSize](VmSize)
about 600Kbps for the whole test, while the inbound traffic started at
200Kbps and rose to about 1Mbps at the end.
### test two: 1MB mean file size
Same environment as before, but the mean file size was set to 1MB instead of
10kB.
```
clients: 2MBps down, 340kBps up, 1.37 fps down, .36 fps up
tahoecs2: 60% CPU, 14Mbps out, 11Mbps in, load avg .74 (web server)
tahoecs1: 78% CPU, 7Mbps out, 17Mbps in, load avg .91 (web server)
tahoebs4: 26% CPU, 4.7Mbps out, 3Mbps in, load avg .50 (storage server)
tahoebs5: 34% CPU, 4.5Mbps out, 3Mbps in (storage server)
```
Load is about the same as before, but of course the bandwidths are larger.
For this file size, the per-file overhead seems to be more of a limiting
factor than per-byte overhead.
### initial conclusions
So far, Tahoe is scaling as designed: the client nodes are the ones doing