From: Zooko O'Whielacronx Date: Sun, 8 May 2011 12:42:28 +0000 (-0700) Subject: docs: fix several imprecise or inaccurate values in performance.rst X-Git-Tag: allmydata-tahoe-1.9.0b1~5 X-Git-Url: https://git.rkrishnan.org/simplejson/components/%22doc.html/something?a=commitdiff_plain;h=587e31a8cf486031c4ab62754a0d5e7c775c9b15;p=tahoe-lafs%2Ftahoe-lafs.git docs: fix several imprecise or inaccurate values in performance.rst add cpu values for each operation sort the list of values into the same order in each operation refs #1398 --- diff --git a/docs/performance.rst b/docs/performance.rst index 95a05143..4657c151 100644 --- a/docs/performance.rst +++ b/docs/performance.rst @@ -47,7 +47,7 @@ cpu: ~A network: ~N -memory footprint: N/K*S +memory footprint: S when the file is not already uploaded ------------------------------------- @@ -62,19 +62,19 @@ disk: 2*A cpu: 2*~A -network: ~N + ~A +network: N/K*A memory footprint: N/K*S Publishing an ``A``-byte mutable file ===================================== +cpu: ~A + a large constant for RSA keypair generation + network: A memory footprint: N/K*A -cpu: ~A + a large constant for RSA keypair generation - notes: Tahoe-LAFS generates a new RSA keypair for each mutable file that it publishes to a grid. This takes up to 1 or 2 seconds on a typical desktop PC. @@ -86,9 +86,9 @@ files, this may cause Tahoe-LAFS to have an unacceptably large memory footprint Downloading ``B`` bytes of an ``A``-byte immutable file ======================================================= -network: B +cpu: ~B -cpu: ~A +network: B notes: When Tahoe-LAFS 1.8.0 or later is asked to read an arbitrary range of an immutable file, only the S-byte segments that overlap the @@ -101,6 +101,8 @@ the rest of the file even after the request was satisfied.) Downloading ``B`` bytes of an ``A``-byte mutable file ===================================================== +cpu: ~A + network: A memory footprint: A @@ -112,6 +114,8 @@ exploring fixes for this; see ticket #393 for more information. Modifying ``B`` bytes of an ``A``-byte mutable file =================================================== +cpu: ~A + network: A memory footprint: N/K*A @@ -127,6 +131,8 @@ the existing RSA keypair instead of generating a new one. Inserting/Removing ``B`` bytes in an ``A``-byte mutable file ============================================================ +cpu: ~A + network: A memory footprint: N/K*A @@ -144,9 +150,11 @@ file". Adding an entry to an ``A``-entry directory =========================================== +cpu: ~A + network: ~A -memory footprint: N/K*A +memory footprint: N/K*~A notes: In Tahoe-LAFS, directories are implemented as specialized mutable files. So adding an entry to a directory is essentially adding B @@ -155,9 +163,11 @@ files. So adding an entry to a directory is essentially adding B Listing an ``A`` entry directory ================================ +cpu: ~A + network: ~A -memory footprint: N/K*A +memory footprint: N/K*~A notes: Listing a directory requires that the mutable file storing the directory be downloaded from the grid. So listing an A entry @@ -167,7 +177,9 @@ file, since each directory entry is about 300-330 bytes in size. Performing a file-check on an ``A``-byte file ============================================= -network: ~G, where G is the number of servers on your grid +cpu: ~G + +network: ~G memory footprint: negligible @@ -179,24 +191,29 @@ and repair operations. Performing a file-verify on an ``A``-byte file ============================================== +cpu: ~N/K*A + network: N/K*A memory footprint: N/K*S notes: To verify a file, Tahoe-LAFS downloads all of the ciphertext -shares that were originally uploaded to the grid and integrity -checks them. This is, for well-behaved grids, likely to be more -expensive than downloading an A-byte file, since only a fraction -of these shares are necessary to recover the file. +shares that were originally uploaded to the grid and integrity checks +them. This is (for well-behaved grids) more expensive than downloading +an A-byte file, since only a fraction of these shares are necessary to +recover the file. Repairing an ``A``-byte file (mutable or immutable) =================================================== -network: variable; up to around ~A +cpu: variable, between ~A and ~N/K*A + +network: variable; between A and N/K*A -memory footprint: from S to (1+N/K)*S +memory footprint: (1+N/K)*S -notes: To repair a file, Tahoe-LAFS downloads the file, and generates/uploads -missing shares in the same way as when it initially uploads the file. -So, depending on how many shares are missing, this can be about as -expensive as initially uploading the file in the first place. +notes: To repair a file, Tahoe-LAFS downloads the file, and +generates/uploads missing shares in the same way as when it initially +uploads the file. So, depending on how many shares are missing, this +can cost as little as a download or as much as a download followed by +a full upload.