summaryrefslogtreecommitdiff
path: root/66/2804577d3462af99f6093258511dd5275bf2e4
blob: 2d6637e7486383ee9b555cf0d3c40cfcb5707a03 (plain)
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
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7686B707
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 17:58:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net
	[217.70.183.195])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9500E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 17:58:55 +0000 (UTC)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154])
	by relay3-d.mail.gandi.net (Postfix) with ESMTP id 490A1A80B1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 19:58:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
	by mfilter26-d.gandi.net (mfilter26-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024) with ESMTP id 4kS2l4pMFJy3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 19:58:52 +0200 (CEST)
X-Originating-IP: 85.181.106.88
Received: from [192.168.1.2] (x55b56a58.dyn.telefonica.de [85.181.106.88])
	(Authenticated sender: thomasv@electrum.org)
	by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BCA85A80AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 19:58:52 +0200 (CEST)
Message-ID: <55B12B5C.3000108@electrum.org>
Date: Thu, 23 Jul 2015 19:58:52 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: 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: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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:58:56 -0000

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 =E9crit :
> Similar to the Bitcoin Node Speed Test, this is a quick quantitative lo=
ok at how the Electrum server software handles under load. The Electrum w=
allet is extremely popular, and the distributed servers which power it ar=
e all hosted by volunteers without budget. The server requires a fully in=
dexed Bitcoin Core daemon running, and produces sizable external index in=
 order to allow SPV clients to quickly retrieve their history.=20
>=20
>     3.9G    electrum/utxo
>     67M     electrum/undo
>     19G     electrum/hist
>     1.4G    electrum/addr
>     24G     electrum/
>=20
> 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 minut=
es per megabyte of block to process into the index. This seems to hold tr=
ue through the 10 or so blocks I have in my scroll buffer, the contents o=
f 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 s=
upport up to 2.64 MB block sizes before permanently falling behind the ch=
ain.=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20