* [bitcoin-dev] Electrum Server Speed Test
@ 2015-07-23 15:56 Slurms MacKenzie
2015-07-23 17:18 ` Joseph Gleason ⑈
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Slurms MacKenzie @ 2015-07-23 15:56 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 15:56 [bitcoin-dev] Electrum Server Speed Test Slurms MacKenzie
@ 2015-07-23 17:18 ` Joseph Gleason ⑈
2015-07-23 17:28 ` Matt Whitlock
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Joseph Gleason ⑈ @ 2015-07-23 17:18 UTC (permalink / raw)
To: Slurms MacKenzie, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
I have concerns about the performance of the Electrum server software as
well. It seems to load data one block at a time (which normally makes
sense) and I think it is even single threaded on transactions inside the
block.
To try to addresses these issues, I made my own implementation of the
electrum server. It doesn't support UTXO (yet) but happily interacts with
all the clients I've tested. It is heavily multithreaded, uses mongodb as
a key value store and bitcoinj for block and transaction parsing.
https://github.com/fireduck64/jelectrum
You can hit a running instance at:
b.1209k.com:50002:s
or
b.1209k.com:50001:t
A synced node uses 347G of mongodb storage.
Here are the recent blocks imported, with number of transactions and import
time.
http://pastebin.com/cfW3C2L6
These times are based on having mongodb on SSD.
The CPU is 8 core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
I'd be happy to help with anything you need to evaluate it.
On Thu, Jul 23, 2015 at 9:01 AM Slurms MacKenzie via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3302 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 15:56 [bitcoin-dev] Electrum Server Speed Test Slurms MacKenzie
2015-07-23 17:18 ` Joseph Gleason ⑈
@ 2015-07-23 17:28 ` Matt Whitlock
2015-07-23 17:41 ` Joseph Gleason ⑈
2015-07-23 17:58 ` Thomas Voegtlin
2015-07-23 18:21 ` Eric Voskuil
3 siblings, 1 reply; 7+ messages in thread
From: Matt Whitlock @ 2015-07-23 17:28 UTC (permalink / raw)
To: Slurms MacKenzie; +Cc: bitcoin-dev
Great data points, but isn't this an argument for improving Electrum Server's database performance, not for holding Bitcoin back?
(Nice alias, by the way. Whimmy wham wham wozzle!)
On Thursday, 23 July 2015, at 5:56 pm, 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 17:28 ` Matt Whitlock
@ 2015-07-23 17:41 ` Joseph Gleason ⑈
0 siblings, 0 replies; 7+ messages in thread
From: Joseph Gleason ⑈ @ 2015-07-23 17:41 UTC (permalink / raw)
To: Matt Whitlock, Slurms MacKenzie; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
I think our friendly original party worm is just trying to evaluate where
we are currently so arguments can be based on data.
I would tend to agree that there are performance improvements to be made
and would rather do that work than limit the block size.
On Thu, Jul 23, 2015 at 10:28 AM Matt Whitlock via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Great data points, but isn't this an argument for improving Electrum
> Server's database performance, not for holding Bitcoin back?
>
> (Nice alias, by the way. Whimmy wham wham wozzle!)
>
>
> On Thursday, 23 July 2015, at 5:56 pm, 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.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3033 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 15:56 [bitcoin-dev] Electrum Server Speed Test Slurms MacKenzie
2015-07-23 17:18 ` Joseph Gleason ⑈
2015-07-23 17:28 ` Matt Whitlock
@ 2015-07-23 17:58 ` Thomas Voegtlin
2015-07-23 18:21 ` Eric Voskuil
3 siblings, 0 replies; 7+ messages in thread
From: Thomas Voegtlin @ 2015-07-23 17:58 UTC (permalink / raw)
To: bitcoin-dev
There is some room for optimization in the Electrum server:
- the utxo database (patricia tree) should be made a binary tree.
- the server is written in python, which is slow.
I am not too worried about the short-term; a block takes on average 15s
to process on my server. For example, here are the last blocks in my log:
[23/07/2015-17:11:57] catch_up: block 366604 (0.145s 27.278s)
[23/07/2015-17:37:55] catch_up: block 366605 (0.126s 24.453s)
[23/07/2015-17:50:23] catch_up: block 366606 (0.133s 21.666s)
[23/07/2015-18:03:22] catch_up: block 366607 (0.110s 31.680s)
[23/07/2015-18:11:14] catch_up: block 366608 (0.093s 18.269s)
[23/07/2015-18:26:38] catch_up: block 366609 (0.115s 27.925s)
[23/07/2015-18:29:07] catch_up: block 366610 (0.062s 8.163s)
[23/07/2015-18:44:18] catch_up: block 366611 (0.118s 21.294s)
[23/07/2015-18:52:14] catch_up: block 366612 (0.075s 12.535s)
[23/07/2015-18:58:54] catch_up: block 366613 (0.100s 17.857s)
[23/07/2015-19:04:18] catch_up: block 366614 (0.061s 11.174s)
[23/07/2015-19:10:31] catch_up: block 366615 (0.064s 10.151s)
[23/07/2015-19:11:04] catch_up: block 366616 (0.035s 2.962s)
[23/07/2015-19:19:53] catch_up: block 366617 (0.081s 13.125s)
[23/07/2015-19:25:23] catch_up: block 366618 (0.037s 8.377s)
[23/07/2015-19:28:08] catch_up: block 366619 (0.044s 3.984s)
[23/07/2015-19:30:36] catch_up: block 366620 (0.051s 6.105s)
[23/07/2015-19:40:05] catch_up: block 366621 (0.058s 14.632s)
[23/07/2015-19:42:10] catch_up: block 366622 (0.040s 4.143s)
That server is a Hetzner EX40 box, rented for 50 eur/month. Of course if
you run the electrum server on a cheap VPS, performance might not be as
good.
Le 23/07/2015 17:56, Slurms MacKenzie via bitcoin-dev a écrit :
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 15:56 [bitcoin-dev] Electrum Server Speed Test Slurms MacKenzie
` (2 preceding siblings ...)
2015-07-23 17:58 ` Thomas Voegtlin
@ 2015-07-23 18:21 ` Eric Voskuil
2015-07-23 18:26 ` Slurms MacKenzie
3 siblings, 1 reply; 7+ messages in thread
From: Eric Voskuil @ 2015-07-23 18:21 UTC (permalink / raw)
To: Slurms MacKenzie, bitcoin-dev
-----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-----
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Electrum Server Speed Test
2015-07-23 18:21 ` Eric Voskuil
@ 2015-07-23 18:26 ` Slurms MacKenzie
0 siblings, 0 replies; 7+ messages in thread
From: Slurms MacKenzie @ 2015-07-23 18:26 UTC (permalink / raw)
To: Eric Voskuil; +Cc: bitcoin-dev
That's purely the time on the wall for electrum-server, validation in bitcoind happens before. As ThomasV has pointed out it is significantly faster with a solid state disk (but much more expensive to operate), if we get to that point it'll only be expensive servers with lots of SSD space which are able to keep up with the current software.
I was mostly trying to make a point about other software being impacted in ways which aren't really discussed, rather than a specific dig about electrum-server. I should have made that more clear.
> Sent: Thursday, July 23, 2015 at 9:21 PM
> From: "Eric Voskuil" <eric@voskuil•org>
> To: "Slurms MacKenzie" <slurms@gmx•us>, bitcoin-dev@lists•linuxfoundation.org
> Subject: Re: [bitcoin-dev] Electrum Server Speed Test
>
> -----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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-07-23 18:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-23 15:56 [bitcoin-dev] Electrum Server Speed Test Slurms MacKenzie
2015-07-23 17:18 ` Joseph Gleason ⑈
2015-07-23 17:28 ` Matt Whitlock
2015-07-23 17:41 ` Joseph Gleason ⑈
2015-07-23 17:58 ` Thomas Voegtlin
2015-07-23 18:21 ` Eric Voskuil
2015-07-23 18:26 ` Slurms MacKenzie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox