From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2653E482 for ; 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 ; Thu, 23 Jul 2015 17:41:28 +0000 (UTC) Received: by wibud3 with SMTP id ud3so34672866wib.1 for ; 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: <1690410.cgD4NDVhNv@crushinator> In-Reply-To: <1690410.cgD4NDVhNv@crushinator> From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= Date: Thu, 23 Jul 2015 17:41:17 +0000 Message-ID: To: Matt Whitlock , Slurms MacKenzie 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 t= o 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 bit= coin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
Great data points, but isn't this an argument for improvi= ng 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 wro= te:
> 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.
>
>=C2=A0 =C2=A0 =C2=A03.9G=C2=A0 =C2=A0 electrum/utxo
>=C2=A0 =C2=A0 =C2=A067M=C2=A0 =C2=A0 =C2=A0electrum/undo
>=C2=A0 =C2=A0 =C2=A019G=C2=A0 =C2=A0 =C2=A0electrum/hist
>=C2=A0 =C2=A0 =C2=A01.4G=C2=A0 =C2=A0 electrum/addr
>=C2=A0 =C2=A0 =C2=A024G=C2=A0 =C2=A0 =C2=A0electrum/
>
> 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.
> _______________________________________________
> 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/mail= man/listinfo/bitcoin-dev
--001a1134cd38982b0b051b8e65c2--