[tahoe-dev] Doubts on Mutable File Publish timings ?
Brian Warner
warner at lothar.com
Thu Feb 24 11:03:05 PST 2011
On 2/24/11 1:29 AM, sreenivasulu velpula wrote:
>
> I have few doubts about mutable file timings.
>
> + Setup: 193us
> * ( What is set up time ?)*
That's the time spent between the decision to modify a file and the
start of encryption, which includes permutation of the serverlist and
some decisions about where shares ought to go. See
https://github.com/warner/tahoe-lafs/blob/master/src/allmydata/mutable/publish.py
between lines 140 and 241.
> + Encrypting: 91ms (140.17MBps)
> + Encoding: 198ms (64.14MBps)
> + Packing Shares: 371ms (34.26MBps)
> # RSA Signature: 6.0ms
> * (what is packing shares and RSA signature ?)*
"packing shares" is the time spent arranging the encrypted data into the
right format for upload to the servers: some struct.pack() calls, merkle
hash tree generation, and the RSA signature operation (called out
separately). Each share includes an RSA public-key signature to make
sure that only writecap holders can publish valid shares, and the time
spend doing RSA signatures is traditionally a performance concern, so
the timing report lists it separately, in addition to including it in
the overall "Packing Shares" time. Much of the time spent packing the
share is O(n) in size of the share, but the RSA signature time is
constant.
> + Pushing: 15 seconds (830.9kBps)
> o Per-Server Response Times:
> + [wen34nob]: 3.88s
> + [xuqszbmd]: 15 seconds
>
> * (Is it sum of timings for each segment when u send erasure coded
> blocks to servers and getting ACKs from servers ?)*
Mutable file publish operations send exactly one message to each server
(using a 'test-and-set' method), so those per-server response times are
measured from the moment we queue the message for delivery to the time
we get the ACK back from the server. Each message contains the
erasure-coded share, as well as all the integrity/signature information.
hope that helps!
-Brian
More information about the tahoe-dev
mailing list