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
|
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 2653E482
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:41:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
[209.85.212.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74F4A112
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 17:41:28 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so34672866wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 10:41:27 -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
:cc:content-type;
bh=fPKIZgkLMSnMT2dGIGPd9pWHoUmtMKoIlEW1xTJE7Ak=;
b=pazRmS7B5YZjJtzwSHjSq62eTab2YgnwsoN3BoQJGWrFZ8jF7E3dQfI+RhEu8aazHE
2LQr714pvbzk/Ar1GhT4GrT6STVs55ap2M74M89ihrxbQs/wsYraFRQhxNizTlYDnAIP
ktab5mNDw3dh5KFUI2dzVkrzCLYfnyd61hl0SwNEpc+F8eeHFCyZPe3lUWeEKFt0cSmC
qFfFlKB5z9EkwF14CgCIyloZxne28dIzKP7P+GB7PtatlypbeexdmOf0CaZWUO4PGedg
uLMI41YTV2Kk/LcRCpUaMkUpd0Me8hhnqQWVjAKxBBE91Xu52NZt4WsagZy9YW5xbSgT
XYwg==
X-Received: by 10.180.218.227 with SMTP id pj3mr18484871wic.59.1437673287328;
Thu, 23 Jul 2015 10:41:27 -0700 (PDT)
MIME-Version: 1.0
References: <trinity-c358bbcc-a5d1-487f-9aae-730241fc4eac-1437666965282@3capp-mailcom-bs12>
<1690410.cgD4NDVhNv@crushinator>
In-Reply-To: <1690410.cgD4NDVhNv@crushinator>
From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= <fireduck@gmail.com>
Date: Thu, 23 Jul 2015 17:41:17 +0000
Message-ID: <CA+ASnrH7KWFZMPNOXFs0ijV-dKE3AbC8iu_mnZYqcgs2TxffLA@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>, Slurms MacKenzie <slurms@gmx.us>
Content-Type: multipart/alternative; boundary=001a1134cd38982b0b051b8e65c2
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
Cc: bitcoin-dev@lists.linuxfoundation.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:41:29 -0000
--001a1134cd38982b0b051b8e65c2
Content-Type: text/plain; charset=UTF-8
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
>
--001a1134cd38982b0b051b8e65c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think our friendly original party worm is just trying to=
evaluate where we are currently so arguments can be based on data.<div><br=
></div><div>I would tend to agree that there are performance improvements t=
o be made and would rather do that work than limit the block size.</div><di=
v><br><div><br></div><div><br></div></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">On Thu, Jul 23, 2015 at 10:28 AM Matt Whitlock via bit=
coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Great data points, but isn't this an argument for improvi=
ng Electrum Server's database performance, not for holding Bitcoin back=
?<br>
<br>
(Nice alias, by the way. Whimmy wham wham wozzle!)<br>
<br>
<br>
On Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev wro=
te:<br>
> Similar to the Bitcoin Node Speed Test, this is a quick quantitative l=
ook at how the Electrum server software handles under load. The Electrum wa=
llet is extremely popular, and the distributed servers which power it are a=
ll 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.<br>
><br>
>=C2=A0 =C2=A0 =C2=A03.9G=C2=A0 =C2=A0 electrum/utxo<br>
>=C2=A0 =C2=A0 =C2=A067M=C2=A0 =C2=A0 =C2=A0electrum/undo<br>
>=C2=A0 =C2=A0 =C2=A019G=C2=A0 =C2=A0 =C2=A0electrum/hist<br>
>=C2=A0 =C2=A0 =C2=A01.4G=C2=A0 =C2=A0 electrum/addr<br>
>=C2=A0 =C2=A0 =C2=A024G=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 minute=
s 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 blo=
cks seem to be of approximately the same processing load. Continuing this t=
rend with the current inter-block time of 9.8 minutes, an electrum-server i=
nstance running on modest-high end dedicated server is able to support up t=
o 2.64 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"_bl=
ank">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=
/mailman/listinfo/bitcoin-dev</a><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>
--001a1134cd38982b0b051b8e65c2--
|
