From 8847b05e781c79fe47fd25be2de6892d19641da9 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Wed, 19 Dec 2007 04:13:07 +0000
Subject: [PATCH] add mostly-download load test data

[Imported from Trac: page Performance, version 25]
---
 Performance.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Performance.md b/Performance.md
index 2ec1d93..5b553cb 100644
--- a/Performance.md
+++ b/Performance.md
@@ -177,6 +177,23 @@ 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.
 
+### test three: 80% upload, 20% download, 1MB mean file size
+
+Same environment as test 2, but 80% of the operations are uploads.
+
+```
+clients: 150kBps down, 680kBps up, .14 fps down, .67 fps up
+tahoecs1: 62% CPU, 11Mbps out, 2.9Mbps in, load avg .85
+tahoecs2: 57% CPU, 10Mbps out, 4Mbps in, load avg .76
+tahoebs4: 16% CPU, 700kBps out, 5.4Mbps in, load avg 0.4ish
+tahoebs5: 21%, 870kBps out, 5.1Mbps in, load avg about 0.35
+```
+
+Overall throughput is about half of the download case. Either uploading files
+or modifying the dirnodes looks to be more expensive than downloading. The
+CPU usage on the web servers was lower, suggesting that the expense might be
+in round trips rather than actual computation.
+
 ### initial conclusions
 
 So far, Tahoe is scaling as designed: the client nodes are the ones doing