How many concurrent requests can an Ethereum node handle?

Question

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?

Answer 1

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

Answer 2

This question was posted quite a while ago; however, the answers seem to be somewhat outdated, as the numbers posted range in the 100's, to 1024, to under 2,000.

Here's an actual benchmark:

Hardware:

Bare metal cloud server

• CPU: E3-1270v6
• RAM: 32GB
• HD: SSD

This is simply a benchmark of calls to eth_blockNumber, and Parity has no problem with ~40k req/s via HTTP, and ~70k req/s via IPC, using the rust-web3 client library (version 0.2.0 at the time of this writing).

Of course, this is not indicative of real-world performance. We have a service that makes more resource intensive rpc calls (a combination of parity_pendingTransactions and trace_transaction, polling the full tx pool - not eth_getFilterChanges), and a single Parity node serves a sustained >20k req/s via the websocket endpoint (custom web3 client written in Rust, using the ws-rs websocket library, single threaded, unoptimized development code).

Answer 3

Not sure if it helps, but my Parity node on my laptop is able to process not more than 2000 eth_call requests per second.

While importing the chain it's limited to around 200 transactions processed per second. With high-end hardware it's quite probable to reach numbers 5-10x of that, but that's nothing I have available right now.

It's worth to mention that there are so many different RPC requests available and also so many different kinds of Ethereum transactions regarding the complexity, so these numbers should be consumed with caution.

Answer 4

Off topic here. It certainly won't win the bounty, but QuickBlocks hits the RPC once (it's slow) and then caches the data on disc (SSD much preferred) to be re-delivered much faster the next time it's requested.

We're seeing sustained access to the exact same data as the RPC at more than 100 times faster speeds, this on a Mac laptop and fully decentralized.

Yes--we've doubled the disc storage requirement, yes--the data is leaking out from under consensus (so is MyEtherWallet and Infura in that sense), but it's really fast, and with super-fast data we can do all sorts of interesting stuff like build cap tables for ERC20 tokens locally, analyze a contract's gas usage, etc.

Answer 5

Since there aren't any answers yet...

I would say the number, on a private chain using commodity desktop hardware, is under 10 000 and probably closer to a few hundred, depending on the nature of the transactions. A fast web server like nginx can handle somewhat more than that about that many in a single thread (see here). But the RPC calls are not as simple as serving up a static page that can be cached. Firstly, there may be dependencies for transactions which require sequential execution of transactions. This can be sped up with speculative evaluation over multiple cores. However, unless you keep the whole blockchain in RAM, you'll still need to hit the disk sometimes. A good SSD can serve on the order of 100k IOPS, but is still a big limit for databases. E.g., Lehtinen found that his SSD could crank out about 1000 tps.

Much beyond this, your computer will probably start dropping TCP connections.

As you can tell, I have not actually tested this and you should treat these numbers as such!