sei-load

A load testing tool for Sei Chain that generates transactions and measures performance.

Quick Start

1. Build

make build

2. Create Config

cp profiles/local.json my-config.json

Edit my-config.json:

{
  "endpoints": ["http://localhost:8545"],
  "chainId": 713714,
  "scenarios": [
    {"name": "EVMTransfer", "weight": 100}
  ],
  "accounts": {
    "count": 100,
    "newAccountRate": 0.1
  },
  "settings": {
    "tps": 100,
    "statsInterval": "10s",
    "bufferSize": 1000,
    "trackUserLatency": true
  }
}

3. Run

./seiload --config my-config.json

Command Line Options

Examples

Basic Load Test

./seiload --config my-config.json --tps 100

High Throughput Test

./seiload --config my-config.json --buffer-size 2000 --max-in-flight 20000

Debug Mode

./seiload --config my-config.json --debug --dry-run

With Receipt Tracking

./seiload --config my-config.json --track-receipts --track-blocks

User Latency Monitoring

./seiload --config my-config.json --track-user-latency --stats-interval 5s

Configuration

Basic Structure

{
  "endpoints": ["http://localhost:8545"],
  "chainId": 713714,
  "scenarios": [...],
  "accounts": {...},
  "settings": {...}
}

Scenarios

"scenarios": [
  {"name": "EVMTransfer", "weight": 50},
  {"name": "ERC20", "weight": 30},
  {"name": "ERC721", "weight": 20}
]

Account Management

"accounts": {
  "count": 100,
  "newAccountRate": 0.1
}

Settings

"settings": {
  "tps": 100,
  "statsInterval": "10s",
  "bufferSize": 1000,
  "trackUserLatency": true
}

Settings Precedence: CLI flags > Config file settings > Default values

Available settings:

• tps: Transactions per second (0 = unlimited)
• statsInterval: Stats logging interval (e.g., "10s", "5m")
• bufferSize: Sender queue size
• dryRun: Simulate without sending transactions
• debug: Enable debug logging
• trackReceipts: Track transaction receipts
• trackBlocks: Track block statistics
• trackUserLatency: Track user latency metrics
• prewarm: Prewarm accounts before test

Available Scenarios

• EVMTransfer: Simple ETH transfers
• ERC20: ERC20 token operations
• ERC20Noop: ERC20 no-op transactions
• ERC20Conflict: ERC20 conflicting transactions
• ERC721: NFT operations

Output

Standard Metrics

throughput tps=133.00, txs=1330, latency(avg=8ms p50=5ms p99=27ms max=494ms)

User Latency (with --track-user-latency)

user latency height=5191 txs=32 min=1s p50=2s max=5s

Block Stats (with --track-blocks)

blocks height=5191 time(p50=2s p99=5s max=8s) gas(p50=21000 p99=50000 max=100000)

Development

Before you push

Run the full local CI gate in one command:

make verify   # check-lint-pin + lint + test + build + CLI --help + check-bindings

make verify mirrors the gating CI jobs (build-and-test, bindings-check): the golangci-lint version-pin check, lint, test, compile the CLI, and a --help smoke. The only gating step it does not run is CI's dry-run smoke (a backgrounded seiload --dry-run killed after 5s) — that asserts no exit code and stays CI-only, so a green verify is a strong signal but not a literal guarantee of that one step. Install the pinned toolchain once first so your local results match CI:

make install-tools   # full toolchain: Node (via nvm), solc, abigen, golangci-lint (pinned to v2.12.2)
# or, for the linter only:
make install-lint    # golangci-lint pinned to v2.12.2

golangci-lint is pinned to a specific version (Makefile GOLANGCI_VERSION, the workflow's golangci-lint-action version:, and .golangci.yml); make lint warns if the binary on your PATH differs. A drifting/unpinned linter is the usual "passes locally, fails CI" trap — make install-lint gives you the exact CI version.

Build

make build

Test

make test   # runs with -race

Lint

make lint

Clean

make clean

Troubleshooting

Connection Issues

• Check endpoint URLs in config
• Verify network connectivity
• Try --dry-run to test config

Low Performance

• Increase --buffer-size
• Increase --max-in-flight for open-loop runs

Memory Issues

• Reduce --buffer-size
• Reduce --max-in-flight for open-loop runs
• Disable receipt tracking