| Flag | Default | Description |
|---|---|---|
--url |
localhost | RTSP URL to test |
--readers |
1000 | Number of concurrent connections |
--duration |
5m | How long each connection stays active |
--rate |
600/m | Connection rate (e.g., 500/s, 1000/m) |
--transport |
tcp | Transport protocol (tcp or udp) |
--real-world |
false | Enable variable load simulation |
--avg-connections |
500 | Average connections for real-world mode |
--include-bad-clients |
false | Include misbehaving clients |
--log |
text | Output format (text or json) |
Requires Go 1.21 or later
For tests exceeding 10,000 connections, see the system tuning guide in the repository.
Tested up to 10,000 on an 8-core system. With proper tuning and multiple source IPs, you can achieve 100,000+ connections. See the multi-IP guide in the repository for scaling beyond 64k.
Go's goroutines use only ~2KB of stack memory vs 1MB+ for OS threads. This allows spawning 100,000+ concurrent connections without complex thread pool management.
No. It establishes RTSP sessions and tracks RTP packets at the protocol level. This means minimal CPU usage and no codec dependencies.
It simulates realistic usage patterns with variable load throughout the day, connection churn, and optionally misbehaving clients. Better for finding memory leaks and resource exhaustion over long runs.
The default file descriptor limit is 1024. Run ulimit -n 1048576 to increase it. For permanent changes, see the system tuning guide.
Yes, but remember bandwidth math: 1,000 connections at 6 Mbps each = 6 Gbps. Use realistic bitrates and monitor your network, not just connection counts.
Questions or issues? support@wink.co
Apache License 2.0