HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tsenart
vegeta
Go2013–2025
tsenart / vegeta

vegeta

HTTP load testing tool and library. It's over 9000!

Web DevelopmentTesting & QualityNetworkingLibraries & SDKs
Explore on GitHubRead Hacker News discussions
22Distinct people
31Mentions
0Explicit recommenders
25.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

HTTP load testing tool and library. It's over 9000!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year31 dated mentions

Observed mentions: 2013-08-17 18:31:27 UTC to 2025-12-23 22:30:56 UTC.

02462013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 3 mentions; 3 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 3 submissions, 4 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC321
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC330
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC321
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC734
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC211
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Vegeta Vegeta is a versatile HTTP load testing tool built out of a need to drill HTTP services with a constant request rate. It's over 9000! Features Usable as a command line tool and a Go library. CLI designed with UNIX composability in mind. Avoids nasty Coordinated Omission. Extensive reporting functionality. Simple to use for distributed load testing. Easy to install and run (static binary, package managers, etc). Install Pre-compiled executables Get them here. macOS You can install Vegeta using the Homebrew: $ brew update && brew install vegeta Or with MacPorts: $ port install vegeta Arch Linux $ pacman -S vegeta FreeBSD On FreeBSD you can install Vegeta with the built in package manager because there is a Vegeta Package available. $ pkg install vegeta Source git clone https://github.com/tsenart/vegeta cd vegeta make vegeta mv vegeta ~/bin # Or elsewhere, up to you. Versioning Both the library and the CLI are versioned with SemVer v2.0.0. After v8.0.0, the two components are versioned separately to better isolate breaking changes to each. CLI releases are tagged with cli/vMAJOR.MINOR.PATCH and published on the GitHub releases page. As for the library, new versions are tagged with both lib/vMAJOR.MINOR.PATCH and vMAJOR.MINOR.PATCH. The latter tag is required for compatibility with go mod. Contributing See CONTRIBUTING.md. Usage manual Usage: vegeta [global flags] <command> [command flags] global flags: -cpus int Number of CPUs to use (default = number of cpus) -profile string Enable profiling of [cpu, heap] -version Print version and exit attack command: -body string Requests body file -cert string TLS client PEM encoded certificate file -chunked Send body with chunked transfer encoding -connect-to value A mapping of (ip|host):port to use instead of a target URL's (ip|host):port. Can be repeated multiple times. Identical src:port with different dst:port will round-robin over the different dst:port pairs. Example: google.com:80:localhost:6060 -connections int Max open idle connections per target host (default 10000) -dns-ttl value Cache DNS lookups for the given duration [-1 = disabled, 0 = forever] (default 0s) -duration duration Duration of the test [0 = forever] -format string Targets format [http, json] (default "http") -h2c Send HTTP/2 requests without TLS encryption -header value Request header -http2 Send HTTP/2 requests when supported by the server (default true) -insecure Ignore invalid server TLS certificates -keepalive Use persistent connections (default true) -key string TLS client PEM encoded private key file -laddr value Local IP address (default 0.0.0.0) -lazy Read targets lazily -max-body value Maximum number of bytes to capture from response bodies. [-1 = no limit] (default -1) -max-connections int Max connections per target host -max-workers uint Maximum number of workers (default 18446744073709551615) -name string Attack name -output string Output file (default "stdout") -prometheus-addr string Prometheus exporter listen address [empty = disabled]. Example: 0.0.0.0:8880 -proxy-header value Proxy CONNECT header -rate value Number of requests per time unit [0 = infinity] (default 50/1s) -redirects int Number of redirects to follow. -1 will not follow but marks as success (default 10) -resolvers value List of addresses (ip:port) to use for DNS resolution. Disables use of local system DNS. (comma separated list) -root-certs value TLS root certificate files (comma separated list) -session-tickets Enable TLS session resumption using session tickets -targets string Targets file (default "stdin") -timeout duration Requests timeout (default 30s) -unix-socket string Connect over a unix socket. This overrides the host address in target URLs -workers uint Initial number of workers (default 10) encode command: -output string Output file (default "stdout") -to string Output encoding [csv, gob, json] (default "json") plot command: -output string Output file (default "stdout") -threshold int Threshold of data points above which series are downsampled. (default 4000) -title string Title and header of the resulting HTML page (default "Vegeta Plot") report command: -buckets string Histogram buckets, e.g.: "[0,1ms,10ms]" -every duration Report interval -output string Output file (default "stdout") -type string Report type to generate [text, json, hist[buckets], hdrplot] (default "text") examples: echo "GET http://localhost/" | vegeta attack -duration=5s | tee results.bin | vegeta report vegeta report -type=json results.bin > metrics.json cat results.bin | vegeta plot > plot.html cat results.bin | vegeta report -type="hist[0,100ms,200ms,300ms]" -cpus Specifies the number of CPUs to be used internally. It defaults to the amount of CPUs available in the system. -profile Specifies which profiler to enable during execution. Both cpu and heap profiles are supported. It defaults to none. -version Prints the version and exits. attack command -body Specifies the file whose content will be set as the body of every request unless overridden per attack target, see -targets. -cert Specifies the PEM encoded TLS client certificate file to be used with HTTPS requests. If -key isn't specified, it will be set to the value of this flag. -chunked Specifies whether to send request bodies with the chunked transfer encoding. -connections Specifies the maximum number of idle open connections per target host. -dns-ttl Specifies the duration to cache DNS lookups for. A zero value caches forever. A negative value disables caching altogether. -max-connections Specifies the maximum number of connections per target host. -duration Specifies the amount of time to issue request to th
Read the full README on GitHub

What Hacker News says

31 sources
jarofgreen·Dec 23, 2025
Some of it is different, but the basics are still the same and still relevant. Just today I've been working with some of this. I took a Django app that's behind an Apache server and added cache-control and vary headers using Django view decorators, and added Header directives to some static files that Apache was serving. This had 2 effects: * Meant I could add mod_cache to the Apache server and have common pages cached and served directly from Apache instead of going back to Django. Load testing with vegeta ( https://github.com/tsenart/vegeta ) shows the server can now handle multiples more simultaneous traffic than it could before. * Meant users browsers now cache all the CSS/JS. As users move between HTML pages, there is now often only 1 request the browser makes. Good for snappier page loads with less server load. But yeah, updating es
Read the rest
pecially the sections on public vs private caches with regards to HTTPS would be good.
In HTTP Caching, a Refresher
ndriscoll·Oct 25, 2022
What's the hardware being used for your test? I get 55k RPS with a basic 200 responder with zio-http[0] (which uses Netty) on my i5-6600K, and over 20k RPS for an e2e POST endpoint that does write batching to postgres (committing the insert before responding to all of the clients in the batch with with their individual db generated ids). Postgres, client (vegeta[1]), and the app all on the same machine. I think that was with keep-alive, I think like 256 clients for the basic responder and 1024 for the one that writes to the db. There's a recently merged PR for zio-http that does 1M RPS on whatever machine they test on[2] so Netty can absolutely scale to high RPS. [0] https://github.com/zio/zio-http [1] https://github.com/tsenart/vegeta [2] https://github.com/zio/zio-http/pull/1659
In Show HN: Open-source non-blocking NIO Java HTTP Server
jillesvangurp·Jan 5, 2021
I've used vegeta (https://github.com/tsenart/vegeta) on a couple of projects. Easy to setup and use. IMHO how you load test is almost as important as where you load test and understanding why. There are three separate reasons to do load testing: 1) Performance testing. Confirm the system does not degrade under a specified load and find out what performance can be expected under these circumstances. This is basically ensuring your system can handle X amount of traffic without issues and knowing your baseline performance. You should get the same kind of response times as you are getting from live server telemetry. 2) Stress testing. finding out what happens when the system is stressed beyond its specs. How does it degrade & where. 3) Reliability testing. Find out how your system breaks and when. The goal here is to try to break the system a
Read the rest
nd test things like failover and making sure you don't lose or corrupt data. Better to die gracefully then abrubtly. If that's new to you, you've been probably doing it wrong because those 3 require very different approaches. I tend to avoid having to do load testing as it sucks up time without telling me much if interest. I instead opt for having decent telemetry on the live system. It will tell me how it performs and where the bottlenecks are. I can set alerts and take action when things degrade (e.g. because of a bad change). Besides there is no substitute for having real users doing real things with real data. And in any case, having telemetry is crucial to do any meaningful stress or reliability testing. Otherwise you just know it degrades without understanding why. There are still valid reasons to do separate load testing of course but I seem to get away with mostly not doing this. When I do, vegeta is what I reach for first. I find most of the need for load testing is requirements related to SLAs or otherwise nervous product owners that need to be reassured. They tend to be more interested in performance tests (i.e. the happy case) whereas technically stress testing is where you learn stuff about your system.
In Load testing is hard and the tools are not great
unclefester90·Jan 20, 2019Submission

Show HN: An HTTP server version of the vegeta load-testing tool

https://github.com/nitishm/vegeta-server/ I am looking for contributors to help me out with my latest project. I am creating an HTTP server implementation, driven by a REST API, for the https://github.com/tsenart/vegeta load testing tool. Currently it is only available as a CLI tool. However, there is an excellent library provided by the author, which is used by the CLI tool. The idea is to create a tool, using vegeta, which is similar to https://github.com/loadimpact/k6 or https://github.com/locustio/locust complete with a UI (frontend). This makes it possible to use this tool in a more distributed manner, and possibly introduce it as a kubernetes native load-testing tool. The project currently supports submitting/viewing/canceling `attack`s (all options are not implemented, yet) and viewing the attack `report`s. Issues are tagged with a
Read the rest
ppropriate labels.
2 points · Open discussion
hobls·Jul 10, 2018
Not to my knowledge. I'd just do something simple by changing your CloudFormation (or Terraform or whatever) templates, deploying the new config, and then running another load test. Could also just spin multiple different versions of the Lambda up, but at some point you need to start getting creative to actually generate enough traffic and running multiple load tests at the same time becomes a pain. When it comes to load testing tools I like Vegeta[1], personally. (Though I've also used some much more complicated proprietary tools when testing at great scale.) 1: https://github.com/tsenart/vegeta
In Comparing Serverless Performance for CPU Bound Tasks

Showing the 15 most recent of 31 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.