clobber is a simple TCP load testing tool written in Rust. It can be a lot of work configuring a load test.
clobber aims to simply throw a lot of traffic at a host, and much of the time that's all you need.
clobber tries to deliver sensible defaults, and easy knobs to turn if you do need more advanced configuration.
clobber uses the
async/await syntax, which currently requires the nightly branch, but is targeted to stabilize some time around the
1.39 release. This project was created as a way to kick the tires of the new syntax, since a network I/O heavy tool is a great use case for an async concurrency model.
My goal for this project is for the code to be performant, easy to read, and idiotmatic. If you see an area that is inefficient or confusing, I would happily welcome the feedback in an issue or PR.
# Only --target/-t is mandatory echo "GET / HTTP/1.1\r\nHost: localhost:8000\r\n\r\n" | clobber --target=0.0.0.0:8000
# Other options can be provided via their own option flags. See Usage for full details. TARGET=0.0.0.0:8000 CONNECTIONS=10000 DURATION=1m30s THREADS=4 # An easy pattern is to save a request to a file, and send it to clobber via the stdin pipe cat my_request | clobber \ --target=$TARGET \ --connections=$CONNECTIONS \ --duration=$DURATION \ --threads=$THREADS
clobber 0.1 tcp load testing tool USAGE: clobber [FLAGS] [OPTIONS] --target <target> FLAGS: -h, --help Prints help information -v Sets the log level, from -v to -vvv -V, --version Prints version information OPTIONS: --connect-timeout <connect-timeout> Timeout for initial TCP syn timeout -c, --connections <connections> Max number of open connections at any given time -d, --duration <duration> Length of the run (e.g. 5s, 10m, 2h, etc...) -l, --limit <limit> Total number of requests --rate <rate> Limit to a particular rate per-second. --read-timeout <read-timeout> Timeout for reading response from target -t, --target <target> Host to clobber --threads <threads> Number of threads
Troubleshooting TCP Performance
Open file limits
A common cause of TCP throughput issues is number of open files. You can check this with
ulimit -n. If you're seeing
issues with number of open files you can raise this limit with
ulimit. If that doesn't work, you may need to edit
/etc/security/limits.conf to raise the limit for your account.
The initial syn phase in the TCP handshake has a long timeout; often in the hundreds of seconds. This is controlled
/proc/sys/net/ipv4/tcp_syn_retries, but even if you set this to a low number a single timeout can take a long
time. This mostly isn't an issue with the intended use case of testing locally running servers with
if your handshake is unreliable you can try configuring the
Knowing when to stop reading from a TCP stream is tricky if you don't know how much data you should read. This is
protocol dependent, and
clobber has no idea. If the server doesn't send an
EOF you can get stuck waiting for more
data for a long time, and this can block connections. With some protocols (such as HTTP) you can send a header like
Connection: close that signals to the host that you won't be sending any more requests, and that they should send
EOF after they've responded. This can fix throughput issues against some HTTP servers. If this isn't possible you
should configure the
read-timeout, but this does have a bit of an impact on top-end performance (especially with a high number of connections.)