Vegeta

External

• https://github.com/tsenart/vegeta

TODO

• https://www.cmscomputing.com/articles/testing/testing-with-vegeta-through-a-web-ui
• https://www.scaleway.com/en/docs/tutorials/load-testing-vegeta/
• https://serialized.net/2017/06/load-testing-with-vegeta-and-python/
• https://qainsights.com/deep-dive-into-vegeta-http-load-testing-tool-and-library/
• https://blog.absyah.dev/super-simple-guide-for-load-testing-using-vegeta
• https://geshan.com.np/blog/2020/09/vegeta-load-testing-primer-with-examples/
• https://isheep.xlog.app/vegeta?locale=en

Internal

• Performance Concepts

Vegeta and Coordinated Omission

Vegeta avoids the coordinated omission problem because it keeps sending requests at constant rate when the system under load starts not responding in time. It does that by increasing the number of workers (goroutines) when the current workers get stuck handling slow requests. Explanation here.

Performance Concepts | Coordinated Omission

Install

Command Line

brew install vegeta

For Development

go get github.com/tsenart/vegeta/v12@v12.11.1

On Linux

wget https://github.com/tsenart/vegeta/releases/download/v12.12.0/vegeta_12.12.0_linux_amd64.tar.gz
tar xfvz ./vegeta_12.12.0_linux_amd64.tar.gz 
rm ./vegeta_12.12.0_linux_amd64.tar.gz
chmod a+x ./vegeta

Command Line Operations

Generate a plot with three different RPS.

Generate the HTTP request in a text file.

Then:

cat request.txt | vegeta attack -insecure -name=10RPS -rate=10 -duration=100s > results.10rps.bin
cat request.txt | vegeta attack -insecure -name=50RPS -rate=50 -duration=100s > results.50rps.bin
cat request.txt | vegeta attack -insecure -name=100RPS -rate=100 -duration=100s > results.100rps.bin
vegeta plot -title "Some Title" results.10rps.bin results.50rps.bin results.100rps.bin > plot.html

To get statistics from the bin file:

vegeta report ./results.10rps.bin

To Read Targets from File

vegeta attack -targets=<file> ...

Filter Output

cat ./results.bin | vegeta encode | jq -c 'del(.body)' | jq

Implementation Details

The Attack() function has a main event loop and "workers" goroutines, one per worker. The number of workers can be increased from the main event loop during an "attack" depending on what?.

Main event loop exit conditions:

1. The attack duration expires.
2. The Pacer says to stop.
3. The stopch is written to.

The "ticks" channel is a conduit for ticks, represented as struct{}s.

What is a tick? The main event loop count counts ticks.

Pacer computes, via the Pace() method, the duration an Attacker should wait until hitting the next Target, given an already elapsed duration and completed hits. If the second return of the Pace() method is true, the Attacker should stop sending hits. Pacer also keeps the instantaneous hit rate per second at a given elapsed time during an attack.

The main event loop Sleep(wait)s after calling the pacer Pace().

An individual worker goroutine blocks reading from ticks channel and for each tick, executes a hit and writes the result on the results channel

Diagram