Message-ID: <55B1309D.7020209@voskuil.org>
Date: Thu, 23 Jul 2015 11:21:17 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Slurms MacKenzie <slurms@gmx.us>, 
 bitcoin-dev@lists.linuxfoundation.org
References: <trinity-c358bbcc-a5d1-487f-9aae-730241fc4eac-1437666965282@3capp-mailcom-bs12>
In-Reply-To: <trinity-c358bbcc-a5d1-487f-9aae-730241fc4eac-1437666965282@3capp-mailcom-bs12>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Electrum Server Speed Test
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does "to process into the index" include time for transport and/or
block validation (presumably by bitcoind) or this this exclusively the
time for Electrum Server to index a validated block?

e

On 07/23/2015 08:56 AM, Slurms MacKenzie via bitcoin-dev wrote:

> Similar to the Bitcoin Node Speed Test, this is a quick
> quantitative
look at how the Electrum server software handles under load. The
Electrum wallet is extremely popular, and the distributed servers
which power it are all hosted by volunteers without budget. The server
requires a fully indexed Bitcoin Core daemon running, and produces
sizable external index in order to allow SPV clients to quickly
retrieve their history.
> 
> 
> 3.9G    electrum/utxo 67M     electrum/undo 19G     electrum/hist 
> 1.4G    electrum/addr 24G     electrum/
> 
> 
> Based on my own logs produced by the electrum-server console, it
takes this server (Xeon, lots of memory, 7200 RPM RAID) approximately
3.7 minutes per megabyte of block to process into the index. This
seems to hold true through the 10 or so blocks I have in my scroll
buffer, the contents of blocks seem to be of approximately the same
processing load. Continuing this trend with the current inter-block
time of 9.8 minutes, an electrum-server instance running on
modest-high end dedicated server is able to support up to 2.64 MB
block sizes before permanently falling behind the chain.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVsTCdAAoJEDzYwH8LXOFOLpgIAIAe5QBTTgpe2kyYrqamUKNI
uasljmNQi3In/rdxNm9Ga+vwTsBg7f4v/xHVrQYAGxdjjZxs0h9bOmAvuc+p2fad
ZeHC/vewrtLxB2aVj5JVbSk5ik57ePyk3SmghTpGMAhgTIWkceIrxR+Fq7TFOlqn
NGnTuBSSsGL9nY57hIFwMJb2CKdPwMVLL/0gjVQ9Llqt+Fu31eSRhDzHOvJnkofO
xwVrVGgST2GE73np3WA0jvzRHjFgsPnQknhjLGQiTgDKsKL0BywE9/Vke2zVNyP7
cAlTQoScEal++9u0h3D475lsxv43V0Rxafc7W0a/OyfXujJ2AlixgV8PlLwhvaY=
=DK5K
-----END PGP SIGNATURE-----