📅 Original date posted:2015-07-23
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2fe297d2/attachment-0001.html>;
Joseph Gleason ⑈ [ARCHIVE] /
npub1qp…my8sw
2023-06-07 15:43:27
in reply to nevent1q…kw2u
Author Public Key
npub1qp59a7k7vxv0k8z277f50092ljk9mjg5du9lz8hlft37u4ggwqes5my8swPublished at
2023-06-07 15:43:27Event JSON
{
"id": "a00f3a8fc70513e787c3a96483291171bc4cfd4c217dbaba26bdb529320227ba",
"pubkey": "00685efade6198fb1c4af79347bcaafcac5dc9146f0bf11eff4ae3ee55087033",
"created_at": 1686152607,
"kind": 1,
"tags": [
[
"e",
"3bf103a91ccfc68d15572c2de8b2ed4dbf981bdf21125d9bbe75c38503c33e24",
"",
"root"
],
[
"e",
"b6bdd69070a346b288f74eff25b1978eae37ee0bd886b29c1a011b286d15fe18",
"",
"reply"
],
[
"p",
"d1e5e343064328be063c36deb0dacb660b8589dcbca90112f9c449503b63ebba"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:I have concerns about the performance of the Electrum server software as\nwell. It seems to load data one block at a time (which normally makes\nsense) and I think it is even single threaded on transactions inside the\nblock.\n\nTo try to addresses these issues, I made my own implementation of the\nelectrum server. It doesn't support UTXO (yet) but happily interacts with\nall the clients I've tested. It is heavily multithreaded, uses mongodb as\na key value store and bitcoinj for block and transaction parsing.\n\nhttps://github.com/fireduck64/jelectrum\n\nYou can hit a running instance at:\nb.1209k.com:50002:s\nor\nb.1209k.com:50001:t\n\nA synced node uses 347G of mongodb storage.\n\nHere are the recent blocks imported, with number of transactions and import\ntime.\nhttp://pastebin.com/cfW3C2L6\nThese times are based on having mongodb on SSD.\nThe CPU is 8 core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz\n\nI'd be happy to help with anything you need to evaluate it.\n\n\nOn Thu, Jul 23, 2015 at 9:01 AM Slurms MacKenzie via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Similar to the Bitcoin Node Speed Test, this is a quick quantitative look\n\u003e at how the Electrum server software handles under load. The Electrum wallet\n\u003e is extremely popular, and the distributed servers which power it are all\n\u003e hosted by volunteers without budget. The server requires a fully indexed\n\u003e Bitcoin Core daemon running, and produces sizable external index in order\n\u003e to allow SPV clients to quickly retrieve their history.\n\u003e\n\u003e 3.9G electrum/utxo\n\u003e 67M electrum/undo\n\u003e 19G electrum/hist\n\u003e 1.4G electrum/addr\n\u003e 24G electrum/\n\u003e\n\u003e Based on my own logs produced by the electrum-server console, it takes\n\u003e this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes\n\u003e per megabyte of block to process into the index. This seems to hold true\n\u003e through the 10 or so blocks I have in my scroll buffer, the contents of\n\u003e blocks seem to be of approximately the same processing load. Continuing\n\u003e this trend with the current inter-block time of 9.8 minutes, an\n\u003e electrum-server instance running on modest-high end dedicated server is\n\u003e able to support up to 2.64 MB block sizes before permanently falling behind\n\u003e the chain.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2fe297d2/attachment-0001.html\u003e",
"sig": "5549d386bbc4bbde17242a0d94083768339a5d32066f6a5dc4b9221d7d01c0d57a548595505722687c49c6fa989a89f6e81df78f0ca33b55d42abb9e2071c3c4"
}