[Ethereum] How many concurrent requests can an Ethereum node handle

go-ethereumnodesparityweb3js

This is a fairly simple question which (I suspect) has a more complex answer. I would like to find out that answer now rather than the hard way down the line.

How many concurrent requests can an Ethereum node handle?

If I have a Parity/Geth node processing transactions to the chain, how much can I hammer it? web3.js communicates with a node utilising the JSON RPC protocol. I assume therefore that the bottleneck is thus the client serving those requests.. I.E the node.

So, does anyone have any insight? If I threw 1,000 pre-signed transactions at the node, what would happen? 10,000? 1 million?

Best Answer

So we actually very, very rarely completely exploded. During big ICOs for instance we were seeing 200k transactions being sent via the MEW node in a single hour, which is about 55 TX/sec. Each transaction consists of:

  • Loading balance

  • Loading token balances

  • Getting network gas price (we no longer do this)

  • Estimating gas (each time the user changes a field)

  • Getting the nonce of an account

  • Actually sending the TX

This had us receiving ~1M requests/hour, or 277 req/s. We have seen DDOS (or dapps) hit as much as 4M requests/hour (but not for a sustained period like an ICO).

During these situations we don't necessarily crash we just have massive latency as it moves through the queue. At some point, depending on your infrastructure, you will obviously completely run out of memory and explode or refuse to accept incoming connections or timeout before it can process anything.

There is also a very large difference between the calls themselves. 5M getBalance requests is different than getting the TX hash or broadcasting a transaction or getting the nonce.

There is also a very large difference between internally attempting to getBalance or sendRawTX and accepting these calls via API / JSON RPC. Locally, we have been able to process 10k transactions in ~7sec. If we dump 10k txs in API, it takes more like 40 seconds to return the TX hash to 10k different users, as long as there aren't 10k other calls thrown in there for confusion.

So, to answer your question, the number of open files in your config file is likely the max right now, which is likely 1024. 😉

The bottlenecks appear at various points, not always the node itself. We have hit bottle necks with TX pool size, CPU, open files, and more. We currently run 10 nodes: 5 geth and 5 parity. For whatever reason, a few of us are having issues with huge latency spikes on Parity itself right now.

If you want to dive deeper, https://github.com/MyEtherWallet/docker-geth-lb

Related Topic