Help Reproducing 41k TPS Using gravity_bench on Gravity Reth

[bugkiller79]

I’m currently testing the performance of gravity-reth and trying to reproduce the 41k TPS result.

I used your code from:
https://github.com/Galxe/gravity_bench
together with:
https://github.com/Galxe/gravity-reth

I ran the benchmark on a Google Cloud VM with 8 vCPUs and 32 GB RAM, but the result is quite different from what you reported in the public (~ 41k tps). In my test, each block only contains around 1,500 transactions, far from the expected throughput.

Could you please share:

What machine/instance type you used (CPU, RAM, storage, network)?

Any specific configurations or tuning required when running gravity_bench?

Whether there are additional steps needed beyond the README?

Thank you very much for your time and help.

[bugkiller79]

@ByteYue

[bugkiller79]

@keanji-x

[keanji-x]

In bench_config.toml, do you set the target_tps to a higher number? The default is 10,000 - could this be limiting the benchmark performance?

[bugkiller79]

I am running a benchmark against reth with the following setup:
Run reth node in the first VM

reth node --dev --datadir "$DATA_DIR" \
    --http --http.api eth,net,web3,admin,debug,txpool \
    --http.addr 0.0.0.0 --http.port 8545 --http.corsdomain "*" \
    --builder.gaslimit "$BUILDER_GAS_LIMIT" \
    --authrpc.addr 0.0.0.0 --authrpc.port "$ENGINE_PORT" --authrpc.jwtsecret "$jwt_file" \
    --rpc.max-connections 10000 \
    --addr 0.0.0.0 --port "$P2P_PORT" \
    --txpool.max-new-txns 102400 \
    --txpool.max-account-slots 102400 \
    --txpool.max-pending-txns 102400 \
    --txpool.pending-max-count 102400 \
    --txpool.pending-max-size 128 \
    --txpool.max-new-pending-txs-notifications 102400 \
    --txpool.queued-max-count 102400 \
    --txpool.queued-max-size 128 \
    --gravity.disable-pipe-execution

Then run benchmark witch command from other VM

gravity_bench --config bench_config.toml

My bench_config.toml

# Gravity Bench Configuration File

contract_config_path = "deploy.json"
target_tps = 40000

nodes = [
    { rpc_url = "http://10.0.0.2:8545", chain_id = 1337 },
]

num_tokens = 2
enable_swap_token = false

[faucet]
private_key = "ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
fauce_eth_balance = "1000000000000000000000"
faucet_level = 10
wait_duration_secs = 60

[accounts]
num_accounts = 100000

[performance]
num_senders = 1500
max_pool_size = 100000
duration_secs = 6000

During the benchmark, I get repeated output tables like these:

And with tps 0.0

Please help me correct setup and choose config to reach benchmark 41k tps

[keanji-x]

For the output, this means all addresses were successfully funded via faucet, but the ERC20 transfers were never initiated. That's weird

I think there are issues with the configuration:

1. wait_duration_secs = 60: This wait duration is too long. It‘s safe, but it means that we must wait 60s after each LevelFaucetPlan, while the program keep printing "tps 0.0 table". You can try to reduce the wait time
2. duration_secs = 6000: This means we're only benchmarking for 10 minutes. I'm not sure if the test exited because it hit the timeout limit.

The other load testing parameters look fine. My debugging recommendations are:

Incrementally increase both the num_accounts and target_tps values to find the optimal configuration for your setup. Just make sure target_tps stays below num_accounts. And keep sufficient the fauce_eth_balance.

[bugkiller79]

okay - another quick question before i'm going back to try with your suggestion:

what config have you tried? and have you already achieved 41k tps with this benchmark? because i think there would be a few more bottleneck to get through to be able to get 41k tps

[bugkiller79]

For the output, this means all addresses were successfully funded via faucet, but the ERC20 transfers were never initiated. That's weird

I think there are issues with the configuration:

1. wait_duration_secs = 60: This wait duration is too long. It‘s safe, but it means that we must wait 60s after each LevelFaucetPlan, while the program keep printing "tps 0.0 table". You can try to reduce the wait time
2. duration_secs = 6000: This means we're only benchmarking for 10 minutes. I'm not sure if the test exited because it hit the timeout limit.

The other load testing parameters look fine. My debugging recommendations are:

Incrementally increase both the num_accounts and target_tps values to find the optimal configuration for your setup. Just make sure target_tps stays below num_accounts. And keep sufficient the fauce_eth_balance.

thanks for the response - i'll try those soon

[keanji-x]

In previous versions, we have achieved 41k TPS in our testing. Recently, we are preparing our testnet and getting ready to start re-testing our latest version to update the stress testing data and publish a reproducible documentation. For detailed machine configuration, please refer here. The specific hardware configuration is as follows:

Instance: Google Cloud c4-highcpu-16
CPU: 16 vCPUs, 2.3 GHz
Memory: 32 GB
Disk: 1 TB SSD (200 MB/s max throughput, 30,000 max IOPS).

In our testing, the stress testing results are highly correlated with disk bandwidth and memeory size. So if you find bottlenecks, you can check the disk bandwidth and memory size.

The configuration is approximately similar:

contract_config_path = "deploy.json"
target_tps = 40000
nodes = [
    { rpc_url = "http://localhost:8545", chain_id = 7771625 },
]
num_tokens=2
enable_swap_token = false
# Faucet and deployer account configuration
[faucet]
# Private key (example, please replace with real private key)
private_key = "xxxxx"
# Faucet Level: Controls the depth of cascading faucet levels
# Value 10: Enables cascade mode with progression 1 -> 10 -> 100 (amplification chain)
# Value 0: Disables cascading, processes data directly
faucet_level = 10 
# Wait duration in seconds between faucet distribution levels
# If you encounter 'insufficient funds' errors, try increasing this value
wait_duration_secs =  1

# Load testing account configuration
[accounts]
# Number of load testing accounts to generate
num_accounts = 100000

# Performance and stress configuration
[performance]
# Number of concurrent transaction sending tasks inside TxnConsumer
num_senders = 1000
# Maximum capacity of the transaction pool inside Consumer
max_pool_size = 100000
duration_secs = 0

[bugkiller79]

@keanji-x Can you share the gravity-reth command, I've tried with suggest configuration

Gcloud instance: c4-highcpu-16 (16 vCPUs, 32 GB memory)
Storage: gravity-bench-execution(Boot disk) | 100 | Hyperdisk balanced 

Command to run gravity-reth

reth node --dev --datadir "$DATA_DIR" \
    --http --http.api eth,net,web3,admin,debug,txpool \
    --http.addr 0.0.0.0 --http.port 8545 --http.corsdomain "*" \
    --builder.gaslimit "240000000" \
    --authrpc.addr 0.0.0.0 --authrpc.port "$ENGINE_PORT" --authrpc.jwtsecret "$jwt_file" \
    --rpc.max-connections 10000 \
    --addr 0.0.0.0 --port "$P2P_PORT" \
    --txpool.max-new-txns 102400 \
    --txpool.max-account-slots 102400 \
    --txpool.max-pending-txns 102400 \
    --txpool.pending-max-count 102400 \
    --txpool.pending-max-size 128 \
    --txpool.max-new-pending-txs-notifications 102400 \
    --txpool.queued-max-count 102400 \
    --txpool.queued-max-size 128 \
    --gravity.disable-pipe-execution

Bench config

# Gravity Bench Configuration File

# Uniswap configuration file path
contract_config_path = "deploy.json"
target_tps = 40000
nodes = [
    { rpc_url = "http://localhost:8545", chain_id = 1337 },
]
num_tokens=2
enable_swap_token = false
# Faucet and deployer account configuration
[faucet]
# Private key (example, please replace with real private key, the follows is a example of reth)
private_key = "xxxx"
# Faucet ETH balance (amount of ETH to use for faucet operations)
fauce_eth_balance = "1000000000000000000000"  # 1000 ETH in wei
# Faucet Level: Controls the depth of cascading faucet levels
# Value 10: Enables cascade mode with progression 1 -> 10 -> 100 (amplification chain)
# Value 0: Disables cascading, processes data directly
faucet_level = 10
# Wait duration in seconds between faucet distribution levels
# If you encounter 'insufficient funds' errors, try increasing this value
wait_duration_secs = 1

# Load testing account configuration
[accounts]
# Number of load testing accounts to generate
num_accounts = 100000

# Performance and stress configuration
[performance]
# Number of concurrent transaction sending tasks inside TxnConsumer
num_senders = 1000
# Maximum capacity of the transaction pool inside Consumer
max_pool_size = 100000
# Duration of the benchmark in seconds. Set to 0 to run indefinitely.
duration_secs = 3600

Output metric it too low, with max value ~ 3000 tps

But when run block scan the number of transactions in a block is small with maximu 1600txs/block

Please share the gravity-reth command and correct my benchmark's configuration
Many thank!

[keanji-x]

@keanji-x Can you share the gravity-reth command, I've tried with suggest configuration

Gcloud instance: c4-highcpu-16 (16 vCPUs, 32 GB memory)
Storage: gravity-bench-execution(Boot disk) | 100 | Hyperdisk balanced 

Command to run gravity-reth

reth node --dev --datadir "$DATA_DIR" \
    --http --http.api eth,net,web3,admin,debug,txpool \
    --http.addr 0.0.0.0 --http.port 8545 --http.corsdomain "*" \
    --builder.gaslimit "240000000" \
    --authrpc.addr 0.0.0.0 --authrpc.port "$ENGINE_PORT" --authrpc.jwtsecret "$jwt_file" \
    --rpc.max-connections 10000 \
    --addr 0.0.0.0 --port "$P2P_PORT" \
    --txpool.max-new-txns 102400 \
    --txpool.max-account-slots 102400 \
    --txpool.max-pending-txns 102400 \
    --txpool.pending-max-count 102400 \
    --txpool.pending-max-size 128 \
    --txpool.max-new-pending-txs-notifications 102400 \
    --txpool.queued-max-count 102400 \
    --txpool.queued-max-size 128 \
    --gravity.disable-pipe-execution

Bench config

# Gravity Bench Configuration File

# Uniswap configuration file path
contract_config_path = "deploy.json"
target_tps = 40000
nodes = [
    { rpc_url = "http://localhost:8545", chain_id = 1337 },
]
num_tokens=2
enable_swap_token = false
# Faucet and deployer account configuration
[faucet]
# Private key (example, please replace with real private key, the follows is a example of reth)
private_key = "xxxx"
# Faucet ETH balance (amount of ETH to use for faucet operations)
fauce_eth_balance = "1000000000000000000000"  # 1000 ETH in wei
# Faucet Level: Controls the depth of cascading faucet levels
# Value 10: Enables cascade mode with progression 1 -> 10 -> 100 (amplification chain)
# Value 0: Disables cascading, processes data directly
faucet_level = 10
# Wait duration in seconds between faucet distribution levels
# If you encounter 'insufficient funds' errors, try increasing this value
wait_duration_secs = 1

# Load testing account configuration
[accounts]
# Number of load testing accounts to generate
num_accounts = 100000

# Performance and stress configuration
[performance]
# Number of concurrent transaction sending tasks inside TxnConsumer
num_senders = 1000
# Maximum capacity of the transaction pool inside Consumer
max_pool_size = 100000
# Duration of the benchmark in seconds. Set to 0 to run indefinitely.
duration_secs = 3600

Output metric it too low, with max value ~ 3000 tps

But when run block scan the number of transactions in a block is small with maximu 1600txs/block Please share the gravity-reth command and correct my benchmark's configuration Many thank!

You can refer to this document to deploy your own gravity-node. We need to start gravity-sdk as the consensus layer, and gravity-sdk will call gravity-reth's pipeline execution implementation.

[bugkiller79]

I've following the guide how to benchmark but in the branch reth-v1.4.8
I got the compile error

I've tried latest branch dev-1114-bugfix but it did not work

Please suggest the most stable branch to try again

[keanji-x]

For the latest version, you need to generate your genesis.json using this gravity-genesis-contract repo and change the config

If you're working with reth 1.4.8, just update the rust version in the rust-toolchain.toml file.

[bugkiller79]

I had tried to generate your genesis.json using this gravity-genesis-contract repo on branch reth 1.4.8 and other new branches but no one worked.

[bugkiller79]

@ByteYue @keanji-x friendly ping - can you help address this issue together with Galxe/gravity-reth#212? Thanks

[keanji-x]

@ByteYue @keanji-x friendly ping - can you help address this issue together with Galxe/gravity-reth#212? Thanks

Hi~, sorry for the long delay in responding. We've refactored the startup script, and you can use this method to start it up. Hope this helps!
https://github.com/Galxe/gravity-sdk/blob/main/cluster/README.md