📅 Original date posted:2015-07-23
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 17:43:28
in reply to nevent1q…57n3
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:43:28Event JSON
{
"id": "7ed1b7dd87337575391b87d327ab17e7f8a814bf0fe2b35f7637ef810d002396",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686152608,
"kind": 1,
"tags": [
[
"e",
"3bf103a91ccfc68d15572c2de8b2ed4dbf981bdf21125d9bbe75c38503c33e24",
"",
"root"
],
[
"e",
"a00f3a8fc70513e787c3a96483291171bc4cfd4c217dbaba26bdb529320227ba",
"",
"reply"
],
[
"p",
"00685efade6198fb1c4af79347bcaafcac5dc9146f0bf11eff4ae3ee55087033"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:Great data points, but isn't this an argument for improving Electrum Server's database performance, not for holding Bitcoin back?\n\n(Nice alias, by the way. Whimmy wham wham wozzle!)\n\n\nOn Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev wrote:\n\u003e 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. \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 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. \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",
"sig": "574f3f37cd96b7a015e2bf3fa62c0fa6a2c6700769502d62444a2aa40f8f81fa50dea06743516ea16cbaba8e6d02079fa9ef4a977f9bdc10e47b0227c2a9a7af"
}