docs/performance.rst

   1 ============================================
   2 Performance costs for some common operations
   3 ============================================
   4
   5 1.  `Publishing an A-byte immutable file`_
   6 2.  `Publishing an A-byte mutable file`_
   7 3.  `Downloading B bytes of an A-byte immutable file`_
   8 4.  `Downloading B bytes of an A-byte mutable file`_
   9 5.  `Modifying B bytes of an A-byte mutable file`_
  10 6.  `Inserting/Removing B bytes in an A-byte mutable file`_
  11 7.  `Adding an entry to an A-entry directory`_
  12 8.  `Listing an A entry directory`_
  13 9.  `Performing a file-check on an A-byte file`_
  14 10. `Performing a file-verify on an A-byte file`_
  15 11. `Repairing an A-byte file (mutable or immutable)`_
  16
  17 ``K`` indicates the number of shares required to reconstruct the file
  18 (default: 3)
  19
  20 ``N`` indicates the total number of shares produced (default: 10)
  21
  22 ``S`` indicates the segment size (default: 128 KiB)
  23
  24 ``A`` indicates the number of bytes in a file
  25
  26 ``B`` indicates the number of bytes of a file which are being read or
  27 written
  28
  29 ``G`` indicates the number of storage servers on your grid
  30
  31 Most of these cost estimates may have a further constant multiplier: when a
  32 formula says ``N/K*S``, the cost may actually be ``2*N/K*S`` or ``3*N/K*S``.
  33 Also note that all references to mutable files are for SDMF-formatted files;
  34 this document has not yet been updated to describe the MDMF format.
  35
  36 Publishing an ``A``-byte immutable file
  37 =======================================
  38
  39 when the file is already uploaded
  40 ---------------------------------
  41
  42 If the file is already uploaded with the exact same contents, same
  43 erasure coding parameters (K, N), and same added convergence secret,
  44 then it reads the whole file from disk one time while hashing it to
  45 compute the storage index, then contacts about N servers to ask each
  46 one to store a share. All of the servers reply that they already have
  47 a copy of that share, and the upload is done.
  48
  49 disk: A
  50
  51 cpu: ~A
  52
  53 network: ~N
  54
  55 memory footprint: S
  56
  57 when the file is not already uploaded
  58 -------------------------------------
  59
  60 If the file is not already uploaded with the exact same contents, same
  61 erasure coding parameters (K, N), and same added convergence secret,
  62 then it reads the whole file from disk one time while hashing it to
  63 compute the storage index, then contacts about N servers to ask each
  64 one to store a share. Then it uploads each share to a storage server.
  65
  66 disk: 2*A
  67
  68 cpu: 2*~A
  69
  70 network: N/K*A
  71
  72 memory footprint: N/K*S
  73
  74 Publishing an ``A``-byte mutable file
  75 =====================================
  76
  77 cpu: ~A + a large constant for RSA keypair generation
  78
  79 network: A
  80
  81 memory footprint: N/K*A
  82
  83 notes: Tahoe-LAFS generates a new RSA keypair for each mutable file that it
  84 publishes to a grid. This takes up to 1 or 2 seconds on a typical desktop PC.
  85
  86 Part of the process of encrypting, encoding, and uploading a mutable file to a
  87 Tahoe-LAFS grid requires that the entire file be in memory at once. For larger
  88 files, this may cause Tahoe-LAFS to have an unacceptably large memory footprint
  89 (at least when uploading a mutable file).
  90
  91 Downloading ``B`` bytes of an ``A``-byte immutable file
  92 =======================================================
  93
  94 cpu: ~B
  95
  96 network: B
  97
  98 notes: When Tahoe-LAFS 1.8.0 or later is asked to read an arbitrary
  99 range of an immutable file, only the S-byte segments that overlap the
 100 requested range will be downloaded.
 101
 102 (Earlier versions would download from the beginning of the file up
 103 until the end of the requested range, and then continue to download
 104 the rest of the file even after the request was satisfied.)
 105
 106 Downloading ``B`` bytes of an ``A``-byte mutable file
 107 =====================================================
 108
 109 cpu: ~A
 110
 111 network: A
 112
 113 memory footprint: A
 114
 115 notes: As currently implemented, mutable files must be downloaded in
 116 their entirety before any part of them can be read. We are
 117 exploring fixes for this; see ticket #393 for more information.
 118
 119 Modifying ``B`` bytes of an ``A``-byte mutable file
 120 ===================================================
 121
 122 cpu: ~A
 123
 124 network: A
 125
 126 memory footprint: N/K*A
 127
 128 notes: If you upload a changed version of a mutable file that you
 129 earlier put onto your grid with, say, 'tahoe put --mutable',
 130 Tahoe-LAFS will replace the old file with the new file on the
 131 grid, rather than attempting to modify only those portions of the
 132 file that have changed. Modifying a file in this manner is
 133 essentially uploading the file over again, except that it re-uses
 134 the existing RSA keypair instead of generating a new one.
 135
 136 Inserting/Removing ``B`` bytes in an ``A``-byte mutable file
 137 ============================================================
 138
 139 cpu: ~A
 140
 141 network: A
 142
 143 memory footprint: N/K*A
 144
 145 notes: Modifying any part of a mutable file in Tahoe-LAFS requires that
 146 the entire file be downloaded, modified, held in memory while it is
 147 encrypted and encoded, and then re-uploaded. A future version of the
 148 mutable file layout ("LDMF") may provide efficient inserts and
 149 deletes. Note that this sort of modification is mostly used internally
 150 for directories, and isn't something that the WUI, CLI, or other
 151 interfaces will do -- instead, they will simply overwrite the file to
 152 be modified, as described in "Modifying B bytes of an A-byte mutable
 153 file".
 154
 155 Adding an entry to an ``A``-entry directory
 156 ===========================================
 157
 158 cpu: ~A
 159
 160 network: ~A
 161
 162 memory footprint: N/K*~A
 163
 164 notes: In Tahoe-LAFS, directories are implemented as specialized mutable
 165 files. So adding an entry to a directory is essentially adding B
 166 (actually, 300-330) bytes somewhere in an existing mutable file.
 167
 168 Listing an ``A`` entry directory
 169 ================================
 170
 171 cpu: ~A
 172
 173 network: ~A
 174
 175 memory footprint: N/K*~A
 176
 177 notes: Listing a directory requires that the mutable file storing the
 178 directory be downloaded from the grid. So listing an A entry
 179 directory requires downloading a (roughly) 330 * A byte mutable
 180 file, since each directory entry is about 300-330 bytes in size.
 181
 182 Performing a file-check on an ``A``-byte file
 183 =============================================
 184
 185 cpu: ~G
 186
 187 network: ~G
 188
 189 memory footprint: negligible
 190
 191 notes: To check a file, Tahoe-LAFS queries all the servers that it knows
 192 about. Note that neither of these values directly depend on the size
 193 of the file. This is relatively inexpensive, compared to the verify
 194 and repair operations.
 195
 196 Performing a file-verify on an ``A``-byte file
 197 ==============================================
 198
 199 cpu: ~N/K*A
 200
 201 network: N/K*A
 202
 203 memory footprint: N/K*S
 204
 205 notes: To verify a file, Tahoe-LAFS downloads all of the ciphertext
 206 shares that were originally uploaded to the grid and integrity checks
 207 them. This is (for well-behaved grids) more expensive than downloading
 208 an A-byte file, since only a fraction of these shares are necessary to
 209 recover the file.
 210
 211 Repairing an ``A``-byte file (mutable or immutable)
 212 ===================================================
 213
 214 cpu: variable, between ~A and ~N/K*A
 215
 216 network: variable; between A and N/K*A
 217
 218 memory footprint (immutable): (1+N/K)*S
 219               (SDMF mutable): (1+N/K)*A
 220
 221 notes: To repair a file, Tahoe-LAFS downloads the file, and
 222 generates/uploads missing shares in the same way as when it initially
 223 uploads the file.  So, depending on how many shares are missing, this
 224 can cost as little as a download or as much as a download followed by
 225 a full upload.
 226
 227 Since SDMF files have only one segment, which must be processed in its
 228 entirety, repair requires a full-file download followed by a full-file
 229 upload.