HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
wg
wrk
C2012–2024
wg / wrk

wrk

Modern HTTP benchmarking tool

34Distinct people
42Mentions
3Explicit recommenders
40.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Modern HTTP benchmarking tool

GitHub

Where it is used

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

What people are saying

We use locust at work but I HIGHLY recommend wrk for a very robust yet simple load testing tool. https://github.com/wg/wrk And of course, this talk by Gil Tene is fantastic if…

leetrout used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

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

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

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 year42 dated mentions

Observed mentions: 2012-04-03 22:57:01 UTC to 2024-09-15 08:00:52 UTC.

0369122012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024

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
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC211
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC12210
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC312
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303

From the project README

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

Read the project’s introduction
wrk - a HTTP benchmarking tool wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue. An optional LuaJIT script can perform HTTP request generation, response processing, and custom reporting. Details are available in SCRIPTING and several examples are located in scripts/. Basic Usage wrk -t12 -c400 -d30s http://127.0.0.1:8080/index.html This runs a benchmark for 30 seconds, using 12 threads, and keeping 400 HTTP connections open. Output: Running 30s test @ http://127.0.0.1:8080/index.html 12 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 635.91us 0.89ms 12.92ms 93.69% Req/Sec 56.20k 8.07k 62.00k 86.54% 22464657 requests in 30.00s, 17.76GB read Requests/sec: 748868.53 Transfer/sec: 606.33MB Command Line Options -c, --connections: total number of HTTP connections to keep open with each thread handling N = connections/threads -d, --duration: duration of the test, e.g. 2s, 2m, 2h -t, --threads: total number of threads to use -s, --script: LuaJIT script, see SCRIPTING -H, --header: HTTP header to add to request, e.g. "User-Agent: wrk" --latency: print detailed latency statistics --timeout: record a timeout if a response is not received within this amount of time. Benchmarking Tips The machine running wrk must have a sufficient number of ephemeral ports available and closed sockets should be recycled quickly. To handle the initial connection burst the server's listen(2) backlog should be greater than the number of concurrent connections being tested. A user script that only changes the HTTP method, path, adds headers or a body, will have no performance impact. Per-request actions, particularly building a new HTTP request, and use of response() will necessarily reduce the amount of load that can be generated. Acknowledgements wrk contains code from a number of open source projects including the 'ae' event loop from redis, the nginx/joyent/node.js 'http-parser', and Mike Pall's LuaJIT. Please consult the NOTICE file for licensing details. Cryptography Notice This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See http://www.wassenaar.org/ for more information. The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with symmetric algorithms. The form and manner of this distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code.
Read the full README on GitHub

What Hacker News says

42 sources
Cool, I didn't see this tool before. I have tried most open source load testing tools out there, as part of writing a couple of review articles on them (https://grafana.com/blog/2020/03/03/open-source-load-testing...) and my gut reaction is this one looks like a Golang alternative to Wrk (https://github.com/wg/wrk) in that its main feature is speed. I'd bet Wrk still blows it out of the water though - in my testing, no other tool got anywhere close to Wrk's level of performance. Still, if you need scale and want to hammer a single URL with a very large number of requests/second and prefer a Go application (Wrk is written in C) it may be a good alternative.
In Bombardier: Fast cross-platform HTTP benchmarking tool written in Go
Sounds like macOS sucks at web serving :) I guess one lesson not explicitly mentioned is that doing benchmarking on something like macOS can have lot of pitfalls compared to systems more intended for this kind of workload (Linux...). But the mention of wrk immediately stood out as a red flag; there is notable problem with wrk called "coordinated omission": https://github.com/wg/wrk/issues/485 https://github.com/giltene/wrk2 https://news.ycombinator.com/item?id=34148502 Benchmarking is difficult. And there is lot of subtlety on how you set up the client(s) and servers that can impact the results a lot.
In Swift sucks at web serving or does it?
gmassman·May 25, 2022Submission

Ask HN: What's the simplest way to run load tests?

I have a backend API and some test data representing real clients. I can write a wrk script that loops through the test data and sends requests to the backend. However, my development machine is network/connection limited so I'd like to run this on some cloud provisioned platform. What's the simplest tool or PaaS that would meet these needs? It doesn't have to be the most cost effective, I simply need the ability to run many instances of my wrk script. https://github.com/wg/wrk
1 points · Open discussion
We are launching a pricing page in the next month as we are gearing up for launch :) One example of recieving a 50% cost saving is from Amazon Machine Images (AMIs). We compared the cheapest official NGINX AMI available on the Amazon Marketplace[0] and then also ran an NGINX+Unikraft AMI. We ran the same workload using wrk[1] and then checked the bill at the end of the month, roughly $80 vs $40. [0]: https://aws.amazon.com/marketplace/pp/prodview-xogyq23b3mfge [1]: https://github.com/wg/wrk
In The battle of the computing clouds is intensifying
How to run those benchmarks? At that Nim release page: https://nim-lang.org/blog/2021/10/19/version-160-released.ht... Is link to this benchmark: https://web-frameworks-benchmark.netlify.app/result Where nim is 2nd with 200k req/s, but it is using httpbeast: https://github.com/dom96/httpbeast That says it would be more useful to use jester: https://github.com/dom96/jester Jester has 150k req/s. But, when looking at these: https://www.techempower.com/benchmarks/ drogon, actix etc has about 600k req/s . Also redbean has about 600k req/s, when I tested: https://redbean.dev/ I tested like this: git clone https://github.com/wg/wrk.git cd wrk make ./wrk -H 'Accept-Encoding: gzip' -t 12 -c 120 http://127.0.0.1:8080/ When I tested https://caddyserver.com v2, it did show about 800k req/s. It would be very helpful to know how those benchmarks are a
Read the rest
ctually done, so that I could compare what is actually fastest in real world, and not just use some for benchmark tested winning non-realistic code.
In Nim 1.6
I didn't make any coordinated omission changes (I really didn't make many changes in general), so twrk does what wrk does. It attempts to correct it after the fact by looking for requests that took twice as long as average and doing some backfilling[1]. I am no expert where coordinated omission is concerned, but my understanding is that it is most problematic in scenarios where your p90+ latency is high. Looking at the results for the 1.2M req/s test you have the following latencies: p50 203.00us p90 236.00us p99 265.00us p99.99 317.00us pMAX 626.00us If you were to apply wrk's coordinated omission hack to these result, the backfilling only starts for requests that took longer than p50 x 2 (roughly) = 406us, which is probably somewhere between p99.999 and pMAX; a very, very small percentage. I am not claiming th
Read the rest
at wrk's hack is "correct", just that I don't think coordinated omission is a major concern for *this specific workload/environment* 1. https://github.com/wg/wrk/blob/a211dd5a7050b1f9e8a9870b95513...
In Extreme HTTP Performance Tuning
What do you mean "very long article"? You could have used "extensive" or something ;) Anyway, what I've seen when comparing the performance of tools, is that Artillery, which is running on NodeJS, is perhaps the wors performer of all the tools I've tested. I don't know if it's because of NodeJS or that Artillery in itself isn't a very performant piece of software (It also consumes a lot of memory, btw). If you want the highest performance, there is one tool that runs circles around all others (including k6), and that is wrk - https://github.com/wg/wrk - very cool piece of software although it is lacking in terms of functionality so mostly suitable for simpler load testing like hammering single URLs. (I don't know how fast wrk2 is, haven't benchmarked it)
In K6: Like unit testing, for performance
Locust [1] is fantastic for load testing for python or any REST API, it's also nice as wrk. [2] In our startup we used it to test 100,000 users traffic on our python based backend and optimized it continuously. We also used wrk with test cases written in LUA scripts. That too worked fantastic. We did not use bokeh visualization, but just with locusts we could improve the response time by logging and improving sqlalchemy query logs. [1] https://locust.io/ [2] https://github.com/wg/wrk
In Load Testing with Python: Locust Testing and Bokeh Visualization

Showing the 15 most recent of 42 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.