一個乙太坊節點可以處理多少並發請求？
這是一個相當簡單的問題（我懷疑）有一個更複雜的答案。我想現在就找到答案，而不是艱難地走下去。
一個乙太坊節點可以處理多少並發請求？
如果我有一個 Parity/Geth 節點處理鏈上的交易，我可以敲多少？web3.js 使用 JSON RPC 協議與節點通信。因此，我假設瓶頸是服務這些請求的客戶端。即節點。
那麼，有沒有人有任何見解？如果我在節點上拋出 1,000 個預簽名交易，會發生什麼？10,000？百萬？
所以我們實際上非常非常罕見地完全爆炸。例如，在大型 ICO 期間，我們看到一個小時內通過 MEW 節點發送了 20 萬筆交易，大約 55 TX/秒。每筆交易包括：
- 負載平衡
- 載入代幣餘額
- 獲取網路 gas 價格（我們不再這樣做）
- 估算氣體（每次使用者更改欄位時）
- 獲取帳戶的 nonce
- 實際發送 TX
這讓我們每小時收到約 100 萬個請求，即 277 個請求/秒。我們已經看到 DDOS（或 dapps）每小時請求多達 400 萬次（但不像 ICO 那樣持續一段時間）。
在這些情況下，我們不一定會崩潰，我們只是在隊列中移動時有很大的延遲。在某些時候，根據您的基礎架構，您顯然會完全耗盡記憶體並爆炸或拒絕接受傳入連接或超時，然後它才能處理任何事情。
呼叫本身之間也存在很大差異。5M getBalance 請求與獲取 TX 雜湊或廣播交易或獲取 nonce 不同。
內部嘗試 getBalance 或 sendRawTX 與通過 API / JSON RPC 接受這些呼叫之間也存在很大差異。在本地，我們已經能夠在約 7 秒內處理 10k 筆交易。如果我們在 API 中轉儲 10k txs，只要沒有 10k 其他呼叫導致混淆，則將 TX 雜湊返回給 10k 不同使用者需要大約 40 秒。
因此，為了回答您的問題，您的配置文件中打開的文件數可能是目前的最大值，可能是 1024。😉
瓶頸出現在不同的點，並不總是節點本身。我們遇到了 TX 池大小、CPU、打開文件等方面的瓶頸。我們目前執行 10 個節點：5 個 geth 和 5 個 parity。無論出於何種原因，我們中的一些人現在都面臨 Parity 本身出現巨大延遲峰值的問題。
這個問題是很久以前發布的；但是，答案似乎有些過時，因為發布的數字範圍從 100 到 1024 到 2,000 以下。
這是一個實際的基準：
硬體：
裸機雲伺服器
- CPU：E3-1270v6
- 記憶體：32GB
- 高畫質：固態硬碟
這只是呼叫的基準，使用rust-web3客戶端庫（撰寫本文時版本 0.2.0），
eth_blockNumber通過 HTTP 約 40k req/s 和通過 IPC 約 70k req/s 的 Parity 沒有問題）。當然，這並不代表真實世界的表現。我們有一項服務可以進行更多資源密集型 rpc 呼叫（and 的組合
parity_pendingTransactions，trace_transaction輪詢整個 tx 池 - noteth_getFilterChanges），並且單個 Parity 節點通過 websocket 端點提供持續 >20k req/s （用 Rust 編寫的自定義 web3 客戶端） ，使用ws-rs websocket庫，單執行緒，未優化的開發程式碼）。
