1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
Return-Path: <fireduck@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CBCB726
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:19:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8C1BD1A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:19:10 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so3163780wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 10:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-type; bh=pNGcc3DKLD8XvwF9xU8IVny8NWAZgHAiGF0ECw2Xqqc=;
b=yFTdz/KEIi51sCOroBdRJDPqI1Y9H1obS0l6MhAAGgNV4dLfj0iuSuMAwlWKul7CVa
YlfcNn/DtsFuAUthHTEBX0LhOjmiekDpbymgk5k7j9rFBh+rPOr2dB+2fAxx65gxQy96
4v5qlkAYh6h+gqeZaSVgc6RwuQ2gxATzoDok40O/S8d583B/eEZEueGUOjwWGQemw0Ue
rrr3vPriiFUlN4rDnHORd6PUv4bmSAejUBwh+nsbCfl3PmPOH0ALH9UIf7lv/UmZxv5/
DR/Fs+T3RDoJKkg2O14AuLKFo2vOeOtwrMNKzLQUirPtLGbYfjum6nL1xRyiHlw5O6X2
6PtQ==
X-Received: by 10.180.186.34 with SMTP id fh2mr1634494wic.94.1437671949337;
Thu, 23 Jul 2015 10:19:09 -0700 (PDT)
MIME-Version: 1.0
References: <trinity-c358bbcc-a5d1-487f-9aae-730241fc4eac-1437666965282@3capp-mailcom-bs12>
In-Reply-To: <trinity-c358bbcc-a5d1-487f-9aae-730241fc4eac-1437666965282@3capp-mailcom-bs12>
From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= <fireduck@gmail.com>
Date: Thu, 23 Jul 2015 17:18:59 +0000
Message-ID: <CA+ASnrG4mubjKb8qeH0Kus6Ga+7o5L6kV=RNzFTBskiYQdt7sg@mail.gmail.com>
To: Slurms MacKenzie <slurms@gmx.us>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c2630ad80adc051b8e15b6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Electrum Server Speed Test
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 17:19:11 -0000
--001a11c2630ad80adc051b8e15b6
Content-Type: text/plain; charset=UTF-8
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
>
--001a11c2630ad80adc051b8e15b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have concerns about the performance of the Electrum serv=
er software as well.=C2=A0 It seems to load data one block at a time (which=
normally makes sense) and I think it is even single threaded on transactio=
ns inside the block.<div><br></div><div>To try to addresses these issues, I=
made my own implementation of the electrum server.=C2=A0 It doesn't su=
pport UTXO (yet) but happily interacts with all the clients I've tested=
.=C2=A0 It is heavily multithreaded, uses mongodb as a key value store and =
bitcoinj for block and transaction parsing.<br><div><br></div><div><a href=
=3D"https://github.com/fireduck64/jelectrum" target=3D"_blank">https://gith=
ub.com/fireduck64/jelectrum</a><br></div><div><br></div><div>You can hit a =
running instance at:</div><div>b.1209k.com:50002:s<br></div><div>or</div><d=
iv>b.1209k.com:50001:t<br></div><div><br></div><div>A synced node uses 347G=
of mongodb storage. =C2=A0</div><div><br></div><div>Here are the recent bl=
ocks imported, with number of transactions and import time.</div><div><a hr=
ef=3D"http://pastebin.com/cfW3C2L6">http://pastebin.com/cfW3C2L6</a><br></d=
iv><div>These times are based on having mongodb on SSD.</div><div>The CPU i=
s 8 core=C2=A0Intel(R) Xeon(R) CPU E5430 =C2=A0@ 2.66GHz</div><div><br></di=
v><div>I'd be happy to help with anything you need to evaluate it.</div=
><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Th=
u, Jul 23, 2015 at 9:01 AM Slurms MacKenzie via bitcoin-dev <<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">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 index=
ed Bitcoin Core daemon running, and produces sizable external index in orde=
r to allow SPV clients to quickly retrieve their history.<br>
<br>
=C2=A0 =C2=A0 3.9G=C2=A0 =C2=A0 electrum/utxo<br>
=C2=A0 =C2=A0 67M=C2=A0 =C2=A0 =C2=A0electrum/undo<br>
=C2=A0 =C2=A0 19G=C2=A0 =C2=A0 =C2=A0electrum/hist<br>
=C2=A0 =C2=A0 1.4G=C2=A0 =C2=A0 electrum/addr<br>
=C2=A0 =C2=A0 24G=C2=A0 =C2=A0 =C2=A0electrum/<br>
<br>
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 throu=
gh the 10 or so blocks I have in my scroll buffer, the contents of blocks s=
eem to be of approximately the same processing load. Continuing this trend =
with the current inter-block time of 9.8 minutes, an electrum-server instan=
ce running on modest-high end dedicated server is able to support up to 2.6=
4 MB block sizes before permanently falling behind the chain.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--001a11c2630ad80adc051b8e15b6--
|
