Distributed Load Generator for Avalanche
talk.gyuho.dev/distributed-load-generator-avalanche-2022.html
Who am I?
- Gyuho Lee (이규호)
- Protocol Engineer, Ava Labs
- github.com/gyuho
- twitter.com/gyuhox
- t.me/leegyuho (Telegram)
- linkedin.com/in/gyuho
How Do We Load Test Today
Loads from a single machine, no visibility of true TPS
Vision
If we are to simulate real-world workloads, the loads must be generated in a distributed manner with full observability into accepted transaction counts and its timestamps.
Steps and News
- Expose accepted transaction count metrics (at VM)
- Expose last accepted block timestamp at consensus layer
- Control plane to spin up VMs on AWS
- Agent that can generate loads against Avalanche
- Metrics collector to monitor TPS
avalanche-ops/blizzard can automate all these!
Worklogs
Add transaction accepted count metric to subnet-evm
Worklogs
Container size to measure throughput/block size
Worklogs
Unix timestamps for each accepted block, useful for computing TPS
Worklogs
prometheus-manager to match new metrics with regex
Worklogs
prometheus-manager to match new metrics with regex
Worklogs
prometheus-manager to match new metrics with regex
Worklogs
prometheus-manager to match new metrics with regex
Worklogs
Command-line interface to spin up worker machines
Worklogs
Agent that runs on remote machines
Workflow
"blizzardup" control plane spins up worker machines
Workflow
"blizzard" agents send loads in parallel using Rust to generate X/C/subnet-evm loads
Demo
Example metrics while loads are being sent
TPS = (tx_accepted_count cur - prev) / (last_accepted_timestamp cur - prev)
Demo
Example "blizzardup" command
Demo
When "blizzardup" command completes
Roadmap
- Github CI integration
- Improve data collection
- Improve test coverage