public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Joseph Gleason ⑈" <fireduck@gmail•com>
To: Matt Whitlock <bip@mattwhitlock•name>, Slurms MacKenzie <slurms@gmx•us>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Electrum Server Speed Test
Date: Thu, 23 Jul 2015 17:41:17 +0000	[thread overview]
Message-ID: <CA+ASnrH7KWFZMPNOXFs0ijV-dKE3AbC8iu_mnZYqcgs2TxffLA@mail.gmail.com> (raw)
In-Reply-To: <1690410.cgD4NDVhNv@crushinator>

[-- 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 --]

  reply	other threads:[~2015-07-23 17:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 15:56 Slurms MacKenzie
2015-07-23 17:18 ` Joseph Gleason ⑈
2015-07-23 17:28 ` Matt Whitlock
2015-07-23 17:41   ` Joseph Gleason ⑈ [this message]
2015-07-23 17:58 ` Thomas Voegtlin
2015-07-23 18:21 ` Eric Voskuil
2015-07-23 18:26   ` Slurms MacKenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+ASnrH7KWFZMPNOXFs0ijV-dKE3AbC8iu_mnZYqcgs2TxffLA@mail.gmail.com \
    --to=fireduck@gmail$(echo .)com \
    --cc=bip@mattwhitlock$(echo .)name \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=slurms@gmx$(echo .)us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox