System information
Geth version: 1.17.2-stable-be4dc0c4
CL client & version: e.g. lighthouse v8.1.2-3deab9b
OS & Version: Linux:
Ubuntu 24.04.4 LTS
6.8.0-110-generic #110-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 19 15:09:20 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Expected behaviour
Good afternoon Geth team,
I am observing that the same eth_getLogs request is significantly slower on Geth compared to Reth. In my tests, Geth takes around 5–6.6 seconds, while Reth returns the same query in around 0.76–1.04 seconds.
I understand that different clients may have different internal indexing and log filtering implementations, so I do not necessarily expect identical performance. However, the difference seems quite large, so I would like to understand whether this is expected for Geth or whether there is a known configuration/performance tuning option that could improve this.
Actual behaviour
The same eth_getLogs query is around 5–10x slower on Geth than on Reth.
Results:
Geth node 1
Hardware:
VM with 16 CPU cores
Hypervisor CPU: Intel Xeon Gold 5412U
RAM: 40 GB
SSD: Samsung MZQL27T6HBLA-00A07
DNS: 0.000023
Connect: 0.000137
TTFB: 6.652341
Total: 6.657787
Geth node 2
Hardware:
VM with 16 CPU cores
Hypervisor CPU: AMD EPYC 9454P
RAM: 40 GB
SSD: Micron 7450 MTFDKCC7T6TFR
DNS: 0.000016
Connect: 0.000112
TTFB: 4.996553
Total: 5.003284
Reth node 1
Hardware:
VM with 16 CPU cores
CPU: 13th Gen Intel Core i9-13900
RAM: 40 GB
SSD: Samsung MZQL27T6HBLA-00A07
DNS: 0.000015
Connect: 0.000115
TTFB: 0.760477
Total: 0.761522
Steps to reproduce the behaviour
/opt/geth/geth-alltools-linux-amd64-1.17.2-be4dc0c4/geth --datadir=/mnt/ethereum-geth-mainnet/data --mainnet --discovery.port=30303 --port=30303 --syncmode=full --gcmode=archive --history.state=0 --log.format=terminal --metrics --metrics.addr=127.0.0.1 --metrics.port=6000 --authrpc.addr=127.0.0.1 --authrpc.jwtsecret=/mnt/ethereum-geth-mainnet/jwt.hex --authrpc.port=8551 --authrpc.vhosts=* --http --http.addr=0.0.0.0 --http.api=admin,debug,eth,net,trace,txpool,web3,rpc,geth,ots --http.port=8545 --http.vhosts=* --http.rpcprefix=/ --ws --ws.addr=0.0.0.0 --ws.api=admin,debug,eth,net,trace,txpool,web3,rpc,geth,ots --ws.port=8546 --ws.origins=* --ws.rpcprefix=/ --rpc.telemetry=true --rpc.telemetry.endpoint=http://localhost:4318 --rpc.telemetry.tags=network=mainnet
curl -o /tmp/response.txt -s -X POST http://127.0.0.1:8545 \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getLogs",
"params": [
{
"address": [
"0xc329400492c6ff2438472d4651ad17389fcb843a",
"0x33d3b87c957d5cd89b0fb980a29718dcf043b66e",
"0xb26ff591f44b04e78de18f43b46f8b70c6676984",
"0x422f5accc812c396600010f224b320a743695f85",
"0x03bf48b8a1b37fbead1ecabcf15b98b924ffa5ac",
"0x475d3eb031d250070b63fa145f0fcfc5d97c304a",
"0x38b86004842d3fa4596f0b7a0b53de90745ab654",
"0x5198cb44d7b2e993ebdda9cad3b9a0eaa32769d2",
"0xbdea8e677f9f7c294a4556005c640ee505be6925",
"0xd0153899e51c5a0fcc98246ba428cc97bd6f50d3",
"0x948323aa8e5c1743f3d94b26ead4d27ae953c654",
"0x11655f71a58d17ad216f30a491baef3b48f00fc7",
"0xceafa7757b8b302dcb0174d48cf6eabb28963b48",
"0x1c57ea879dd3e8c9fefa8224fdd1fa20dd54211e",
"0x95c17e3d3950a3ef5bc128ddfbc60f885cefb0dc",
"0x4999d54320af7b1f88b2829363c0f32ac7bb9928",
"0xe39b5f5638a209c1a6b6cdffe5d37f7ac99fcc84",
"0x19d0d8e6294b7a04a2733fe433444704b791939a",
"0x971e5b5d4baa5607863f3748febf287c7bf82618",
"0x0c969cec0729487d264716e55f232b404299032c",
"0xb09a50acfff7d12b7d18adef3d1027bc149bad1c",
"0x52cb8a621610cc3ccf498a1981a8ae7ad6b8ab2a",
"0x21dbba985eea6ba7f27534a72ccb292eba1d2c7c",
"0x940750a267c64f3bbce31b948b67cd168f0843fa",
"0x9c0823d3a1172f9ddf672d438dec79c39a64f448",
"0x852463974aee1d6155ce3e3d936e76a101a4af19",
"0x544f45485418341c1a2b3a44404f12302277fffc",
"0x594380c06552a4136e2601f89e50b3b9ad17bd4d",
"0x6460aaa0620f59ce967d80f2a32201bddae72304",
"0xbb4a2f26447e6ec92ba3a944374783fc2c308c1d",
"0xa5ef400eac9abae51aadea24759251815e823244",
"0x7abab3dd7287912f91c74bd8f5e26b0f8c5c7647",
"0x724ac5e7941788d1d378aeac73db40a96c627802",
"0xa3501e86d507e2ccc28a10b0448e4e6dc96d7edc",
"0x950fdf40608800535137c61edf3972c436d680e8"
],
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
],
"fromBlock": "0x1323992",
"toBlock": "0x132562c"
}
]
}' \
-w "\n\nDNS: %{time_namelookup}\nConnect: %{time_connect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n"
Backtrace
System information
Geth version:
1.17.2-stable-be4dc0c4CL client & version: e.g.
lighthousev8.1.2-3deab9bOS & Version: Linux:
Expected behaviour
Good afternoon Geth team,
I am observing that the same
eth_getLogsrequest is significantly slower on Geth compared to Reth. In my tests, Geth takes around 5–6.6 seconds, while Reth returns the same query in around 0.76–1.04 seconds.I understand that different clients may have different internal indexing and log filtering implementations, so I do not necessarily expect identical performance. However, the difference seems quite large, so I would like to understand whether this is expected for Geth or whether there is a known configuration/performance tuning option that could improve this.
Actual behaviour
The same eth_getLogs query is around 5–10x slower on Geth than on Reth.
Results:
Geth node 1
Hardware:
VM with 16 CPU cores
Hypervisor CPU: Intel Xeon Gold 5412U
RAM: 40 GB
SSD: Samsung MZQL27T6HBLA-00A07
Geth node 2
Hardware:
VM with 16 CPU cores
Hypervisor CPU: AMD EPYC 9454P
RAM: 40 GB
SSD: Micron 7450 MTFDKCC7T6TFR
Reth node 1
Hardware:
VM with 16 CPU cores
CPU: 13th Gen Intel Core i9-13900
RAM: 40 GB
SSD: Samsung MZQL27T6HBLA-00A07
Steps to reproduce the behaviour
Backtrace