Open imulmat4 opened 1 year ago
how many concurrent requests does this send? can you play with the --rpc-max-tracing-requests
commandline argument a bit?
how do I run this?
how many concurrent requests does this send? can you play with the
--rpc-max-tracing-requests
commandline argument a bit?how do I run this?
I am just running 1 concurrent request here. And to run it its just a simple python script. You can change the file extension to .py then just run python3 debug_test.py
Feel free to change url = "http://localhost:8545" to whatever your node/http endpoint is.
ah this is running js tracers
thanks for this, I now have something to use for perf improvements of the js tracers
This issue is stale because it has been open for 21 days with no activity.
hey,
we got into the same issue, is there any remediation or any other advice, how to make it faster? Using callTracer works blazing fast, but we need this (in geth/erigon it's working properly)
Thanks
do you have some sample requests and numbers?
base chain, op-reth v1.1.1
{
"jsonrpc": "2.0",
"method": "debug_traceBlockByNumber",
"id": 1,
"params": [
"0x155DE0C",
{
"tracer": "{data: [], fault: function(log) {}, step: function(log) { if(log.op.toString() == '\''CALL'\'' && log.stack.peek(2) != '\''0'\'') this.data.push({address:log.stack.peek(1), value:log.stack.peek(2)}); }, result: function() { return this.data; }}",
"timeout": "10s"
}
]
}
and times (AMD EPYC 7402 24-Core Processor, NVME disks), base archive
real 0m41.129s
user 0m0.009s
sys 0m0.003s
the same with just callTracer
{
"jsonrpc": "2.0",
"method": "debug_traceBlockByNumber",
"id": 1,
"params": ["0x155DE0C", {"tracer":"callTracer"}]
}
...
real 0m0.162s
user 0m0.002s
sys 0m0.016s
Describe the bug
I have quite a few traces that I run on blocks using my erigon node. I was hoping to switch to Reth so I stood up a standard Reth node in docker. Args: ghcr.io/paradigmxyz/reth:v0.1.0-alpha.10 node --chain mainnet --datadir /data/reth --metrics 127.0.0.1:9001 --log.directory /data/ --authrpc.addr 127.0.0.1 --authrpc.port 8551 --authrpc.jwtsecret /data/jwttoken/jwt.hex --http --http.addr 0.0.0.0 --http.port 8545 --http.api "eth,net,web3,debug,trace,txpool" --ws --ws.api "eth,net,debug,web3,trace,txpool" --ws.addr 0.0.0.0 --rpc-max-response-size 200 I noticed that my RPC calls on Reth are taking almost 200x longer. I will attach a test script In the repo steps that I was running to test with both erigon and Reth
Steps to reproduce
debug_test.txt Please just run the above. Had to change the file format to txt from .py because of github. For my archive node its consistent at 230 seconds.
Node logs
No response
Platform(s)
Linux (x86)
What version/commit are you on?
reth Version: 0.1.0-alpha.10 Commit SHA: 1b16d80 Build Timestamp: 2023-09-26T19:06:39.318738288Z Build Features: default,jemalloc Build Profile: maxperf
What database version are you on?
reth db version
Current database version: 1 Local database is uninitialized
What type of node are you running?
Archive (default)
What prune config do you use, if any?
I am not pruning
If you've built Reth from source, provide the full command you used
No response
Code of Conduct