HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
valyala
fasthttp
Go2015–2026
valyala / fasthttp

fasthttp

Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http

Web DevelopmentNetworking
Explore on GitHubRead Hacker News discussions
31Distinct people
34Mentions
0Explicit recommenders
23.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http

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:03:16 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 year34 dated mentions

Observed mentions: 2015-11-23 17:21:48 UTC to 2026-03-07 16:38:31 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 4 submissions, 0 comments20152016-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): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 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): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC440
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 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC404
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC514
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC110
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
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 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
fasthttp Fast HTTP implementation for Go. fasthttp might not be for you! fasthttp was designed for some high performance edge cases. Unless your server/client needs to handle thousands of small to medium requests per second and needs a consistent low millisecond response time fasthttp might not be for you. For most cases net/http is much better as it's easier to use and can handle more cases. For most cases you won't even notice the performance difference. General info and links Currently fasthttp is successfully used by VertaMedia in a production serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server. TechEmpower Benchmark round 23 results Server Benchmarks Client Benchmarks Install Documentation Examples from docs Code examples Awesome fasthttp tools Switching from net/http to fasthttp Fasthttp best practices Related projects FAQ HTTP server performance comparison with net/http In short, fasthttp server is up to 6 times faster than net/http. Below are benchmark results. GOMAXPROCS=1 net/http server: $ GOMAXPROCS=1 go test -bench=NetHTTPServerGet -benchmem -benchtime=10s cpu: Intel(R) Xeon(R) CPU @ 2.20GHz BenchmarkNetHTTPServerGet1ReqPerConn 722565 15327 ns/op 3258 B/op 36 allocs/op BenchmarkNetHTTPServerGet2ReqPerConn 990067 11533 ns/op 2817 B/op 28 allocs/op BenchmarkNetHTTPServerGet10ReqPerConn 1376821 8734 ns/op 2483 B/op 23 allocs/op BenchmarkNetHTTPServerGet10KReqPerConn 1691265 7151 ns/op 2385 B/op 21 allocs/op BenchmarkNetHTTPServerGet1ReqPerConn10KClients 643940 17152 ns/op 3529 B/op 36 allocs/op BenchmarkNetHTTPServerGet2ReqPerConn10KClients 868576 14010 ns/op 2826 B/op 28 allocs/op BenchmarkNetHTTPServerGet10ReqPerConn10KClients 1297398 9329 ns/op 2611 B/op 23 allocs/op BenchmarkNetHTTPServerGet100ReqPerConn10KClients 1467963 7902 ns/op 2450 B/op 21 allocs/op fasthttp server: $ GOMAXPROCS=1 go test -bench=kServerGet -benchmem -benchtime=10s cpu: Intel(R) Xeon(R) CPU @ 2.20GHz BenchmarkServerGet1ReqPerConn 4304683 2733 ns/op 0 B/op 0 allocs/op BenchmarkServerGet2ReqPerConn 5685157 2140 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10ReqPerConn 7659729 1550 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10KReqPerConn 8580660 1422 ns/op 0 B/op 0 allocs/op BenchmarkServerGet1ReqPerConn10KClients 4092148 3009 ns/op 0 B/op 0 allocs/op BenchmarkServerGet2ReqPerConn10KClients 5272755 2208 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10ReqPerConn10KClients 7566351 1546 ns/op 0 B/op 0 allocs/op BenchmarkServerGet100ReqPerConn10KClients 8369295 1418 ns/op 0 B/op 0 allocs/op GOMAXPROCS=4 net/http server: $ GOMAXPROCS=4 go test -bench=NetHTTPServerGet -benchmem -benchtime=10s cpu: Intel(R) Xeon(R) CPU @ 2.20GHz BenchmarkNetHTTPServerGet1ReqPerConn-4 2670654 4542 ns/op 3263 B/op 36 allocs/op BenchmarkNetHTTPServerGet2ReqPerConn-4 3376021 3559 ns/op 2823 B/op 28 allocs/op BenchmarkNetHTTPServerGet10ReqPerConn-4 4387959 2707 ns/op 2489 B/op 23 allocs/op BenchmarkNetHTTPServerGet10KReqPerConn-4 5412049 2179 ns/op 2386 B/op 21 allocs/op BenchmarkNetHTTPServerGet1ReqPerConn10KClients-4 2226048 5216 ns/op 3289 B/op 36 allocs/op BenchmarkNetHTTPServerGet2ReqPerConn10KClients-4 2989957 3982 ns/op 2839 B/op 28 allocs/op BenchmarkNetHTTPServerGet10ReqPerConn10KClients-4 4383570 2834 ns/op 2514 B/op 23 allocs/op BenchmarkNetHTTPServerGet100ReqPerConn10KClients-4 5315100 2394 ns/op 2419 B/op 21 allocs/op fasthttp server: $ GOMAXPROCS=4 go test -bench=kServerGet -benchmem -benchtime=10s cpu: Intel(R) Xeon(R) CPU @ 2.20GHz BenchmarkServerGet1ReqPerConn-4 7797037 1494 ns/op 0 B/op 0 allocs/op BenchmarkServerGet2ReqPerConn-4 13004892 963.7 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10ReqPerConn-4 22479348 522.6 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10KReqPerConn-4 25899390 451.4 ns/op 0 B/op 0 allocs/op BenchmarkServerGet1ReqPerConn10KClients-4 8421531 1469 ns/op 0 B/op 0 allocs/op BenchmarkServerGet2ReqPerConn10KClients-4 13426772 903.7 ns/op 0 B/op 0 allocs/op BenchmarkServerGet10ReqPerConn10KClients-4 21899584 513.5 ns/op 0 B/op 0 allocs/op BenchmarkServerGet100ReqPerConn10KClients-4 25291686 439.4 ns/op 0 B/op 0 allocs/op HTTP client comparison with net/http In short, fasthttp client is up to 4 times faster than net/http. Below are benchmark results. GOMAXPROCS=1 net/http client: $ GOMAXPROCS=1 go test -bench='HTTPClient(Do|GetEndToEnd)' -benchmem -benchtime=10s cpu: Intel(R) Xeon(R) CPU @ 2.20GHz BenchmarkNetHTTPClientDoFastServer 885637 13883 ns/op 3384
Read the full README on GitHub

What Hacker News says

34 sources
kbolino·Mar 7, 2026
From nbio's README: For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues. From gnet's README: gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled. [...] gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services. Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface. However, the net/http package is a different story. It indeed isn't very performant, though one should be careful
Read the rest
to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers. A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make. [1]: https://pkg.go.dev/github.com/valyala/fasthttp [2]: https://pkg.go.dev/github.com/gofiber/fiber/v3
In UUID package coming to Go standard library
Cthulhu_·Jan 28, 2025
The Go HTTP stack is not optimized for raw performance though; there's a number of alternative HTTP stacks written in Go optimized for performance, like fasthttp (https://github.com/valyala/fasthttp). (source: https://www.techempower.com/benchmarks/) Likewise, the standard library NodeJS http stack will not be as performant as a performance optimized alternative. That said, if raw performance is your primary concern, neither Go nor NodeJS will be good enough. There's many more factors to consider.
In Go 1.24's go tool is one of the best additions to the ecosystem in years
emmanueloga_·Dec 4, 2023
Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives. By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]). There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we ju
Read the rest
st need to change the data a little. -- 1: https://github.com/alecthomas/go_serialization_benchmarks 2: https://github.com/golang/go/issues/29766#issuecomment-45492... -- 3: https://github.com/goccy/go-json 4: https://github.com/vmihailenco/msgpack 5: https://github.com/fxamacker/cbor -- 6: https://github.com/valyala/fasthttp#faq -- 7: https://github.com/tidwall/gjson 8: https://github.com/tidwall/sjson
In Gobs of data (2011)
craftuser·Jan 9, 2023
I'd love to hear if anyone has other alternatives. I'm finding myself in a similar place as you do. I found on the About and Terms pages a few software projects listed, which the author claims are what powers Slimvoice: - https://www.blender.org - https://www.gimp.org - https://golang.org General tech ^ and libraries: - https://github.com/aymerick/douceur - https://github.com/jung-kurt/gofpdf - https://github.com/lib/pq - https://github.com/qiangxue/fasthttp-routing - https://github.com/valyala/fasthttp - https://github.com/valyala/quicktemplate - https://github.com/bamiaux/rez - https://github.com/MithrilJS/mithril.js And lastly, fonts: - https://github.com/rsms/inter - https://github.com/IBM/plex - https://github.com/weiweihuanghuang/Work-Sans Aggregated from from: - https://slimvoice.co/about - https:
Read the rest
//slimvoice.co/terms Copied URLs just in case those pages go kaput.
In Ask HN: Slimvoice Alternative?
jerf·Nov 29, 2022
"You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now." In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework". There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect to just throw someone a TCP socket and get reasonable work out of them because the web is very complicated nowadays. But the reason why you can "do without a framework" in Go is that it is already a minimal one of its own, and in particular, that "minimality" focuses on providing a mechanism for composing various bits of HTTP code together. So, do you need CSRF protection? Go grab this: https://pkg.go.dev/github.com/gorilla/csr
Read the rest
f It operates with the integrated net/http Go framework to provide CSRF protection. You are objectively not abandoning the ability to have community-written CSRF protection when you go "frameworkless" in Go. Gorilla in general provides lots of mix-and-match pieces: https://www.gorillatoolkit.org/ , like cookie signing: https://pkg.go.dev/github.com/gorilla/securecookie I think calling Go "no framework" is kind of misleading, because I get what you're saying, but the standard library is not the "no framework" option. The "no framework" option is more like using https://github.com/valyala/fasthttp , which is its own server implementation with an incompatible API that does in fact remove you from the community code, other than the code that works only with that server. Don't over-read my post. I am merely saying that Go essentially ships with a minimal framework and so it is misleading to say or think of it as being "frameworkless" (and that is a criticism of the original link, yes), not that it is mandatory to use only that "minimal framework" and all other things on top of it are a bad idea. There are times and places to want large, preconfigured packages of additional functionality. But if there are times and places where it is not desirable, Go does come with a minimalist option by default. It is a pretty good, not-very-opionated option suitable for a standard library, where development is slow and there's not much room for experimentation in what a "full" web framework should look like. The standard library minimalist framework even makes the other frameworks pluggable. You can, for instance, write an API website, then realize that if you need a conventional HTML website, you can plug in a framework for that part, but leave the API part as-is, simply by routing the API URLs to the existing API code while routing the HTML website to the http.Handler provided by the framework. Even "not using an additional framework" is not the commitment it may be in other environments, because the net/http foundation is still there.
In The best Go framework: no framework?
ciprian_craciun·Sep 6, 2022
> fasthttp doesn't implement HTTP/1 correctly Could you point to an issue describe such an improper behavior? > doesn't implement HTTP/2 at all Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144> And I'll quote here what I've said there: > Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy. Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that act
Read the rest
ually supports these is the best approach.
In Static site hosting hurdles
ciprian_craciun·Aug 29, 2022
[Kawipiko's author here] NGinx is great at what it does, however in order to get good performance out of it one must also be a master of its configuration knobs, and knowing all of their implications. For example while benchmarking NGinx I've observed quite different performance characteristics for simple patterns such as asking for `/some-folder/` that fallbacks to `/some-folder/index.html` vs explicitly asking for `/some-folder/index.html`. On the other hand with Kawipiko there aren't many configuration knobs; it is already tuned for a single particular use-case: serving static content for websites (with small resources). Also, a particular use-case where Kawipiko can shine over NGinx, is for a website with lots of small resources (as with my Leaflet tiles example). NGinx can't decide where those resources are placed on disk, thus
Read the rest
the OS file-system caching and read-ahead can't help too much here. Meanwhile with Kawipiko, where everything is bundled together, it receives a lot of help from the OS in this regard. As with regard to the "battle-tested and versatile", Kawipiko uses <https://github.com/valyala/fasthttp> as its HTTP engine, which itself is used in quite a lot of Go-based products, thus one could state that it's "battle-tested enough". :) With regard the "even for a doc server embedded in hardware", why don't you think Kawipiko is a good fit in that case? (In fact this was one of its main use-cases.)
In Kawipiko – fast static HTTP server in Go
ciprian_craciun·Aug 28, 2022
[Kawipiko's author here] The main HTTP "engine" behind Kawipiko is `fasthttp`, <https://github.com/valyala/fasthttp> that supports only HTTP/1.1 (with or without TLS). However for experimentation I've also integrated HTTP/2 and HTTP/3 support, although the performance isn't that great... In fact, there is one ticket open on `fasthttp` about HTTP/2 support, however (as I've also commented on this issue), I don't think that's the way to go for the intended use-cases: <https://github.com/valyala/fasthttp/issues/144> My current opinion is this: HTTP/2, and especially HTTP/3, are mainly meant for CDN's and highly performant HTTP load-balancers (like HAProxy), meanwhile HTTP/1.1 is the best solution for the backend.
In Kawipiko – fast static HTTP server in Go
hardwaresofton·Mar 30, 2021
So the thing is I limited the memory to 100MB (because how much memory could you need to serve 1MB, even if every go-routine stack is 2-5kb and the references are all to one piece of data?) This was an issue, but I found that even with giving it more memory things didn't get much better -- the performance was still much worse. Weirdly enough, net/http did well memory wise (and reasonable performance wise, for Go), but I went to fasthttp since that was what was at the top of benchmarks for go, but the simplest you-would-think-this-would-work code didn't produce the results I would have expected. [EDIT] > edit: looking at their bug tracker, it might also be something like https://github.com/valyala/fasthttp/issues/518: the request is not considered responded to so the goroutines never terminate. I don't know the fasthttp API at all tho, jus
Read the rest
t looked for "leak" on their bug tracker and that stood out So I actually got some help from a reader which was pretty awesome (https://gitlab.com/mrman/kcup-go/-/merge_requests/7), the fasthttp code performed much better after that. I should also mention that I got some advice that didn't pan out -- in particular using fasthttp.ServeFile (https://gitlab.com/mrman/kcup-go/-/merge_requests/9)
In Down the Golang Nil Rabbit Hole
masklinn·Mar 30, 2021
> I ask because I just ran into this working on a tiny project whose only job was to serve a single file[0] (with few resources) and was immediately bit by the OOM killer (I used docker to artificially limit resources). Not a fan of Go but unless your memory limit is extremely low there's no reason for that to happen, the GC does work. So clearly there's some sort of memory leak in the user code, either data being appended to a global, or (more likely?) a goroutine leak of some sort. Maybe check your globals (is there a global slice or map?), and whether all your goroutines will terminate on their own or are guaranteed to only be spawned once? Else it'd be a similar issue in a dependency, looking at kcup.go fasthttp would be the most likely culprit. edit: looking at their bug tracker, it might also be something like https://github.com/val
Read the rest
yala/fasthttp/issues/518: the request is not considered responded to so the goroutines never terminate. I don't know the fasthttp API at all tho, just looked for "leak" on their bug tracker and that stood out
In Down the Golang Nil Rabbit Hole

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