github.com/magiccao/fasthttp
Package fasthttp provides fast HTTP server and client API. Fasthttp provides the following features: Optimized for speed. Easily handles more than 100K qps and more than 1M concurrent keep-alive connections on modern hardware. Optimized for low memory usage. Easy 'Connection: Upgrade' support via RequestCtx.Hijack. Server supports requests' pipelining. Multiple requests may be read from a single network packet and multiple responses may be sent in a single network packet. This may be useful for highly loaded REST services. Server provides the following anti-DoS limits: The number of concurrent connections. The number of concurrent connections per client IP. The number of requests per connection. Request read timeout. Response write timeout. Maximum request header size. Maximum request body size. Maximum request execution time. Maximum keep-alive connection lifetime. Early filtering out non-GET requests. A lot of additional useful info is exposed to request handler: Server and client address. Per-request logger. Unique request id. Request start time. Connection start time. Request sequence number for the current connection. Client supports automatic retry on idempotent requests' failure. Fasthttp API is designed with the ability to extend existing client and server implementations or to write custom client and server implementations from scratch.
Readme
Fast HTTP implementation for Go.
Currently fasthttp is successfully used in a production serving 100K rps from 1M concurrent keep-alive connections on a single server.
Switching from net/http to fasthttp
In short, fasthttp server is up to 10 times faster than net/http. Below are benchmark results.
GOMAXPROCS=1
net/http:
$ GOMAXPROCS=1 go test -bench=NetHTTPServerGet -benchmem -benchtime=5s
PASS
BenchmarkNetHTTPServerGet1ReqPerConn 300000 21236 ns/op 2404 B/op 30 allocs/op
BenchmarkNetHTTPServerGet2ReqPerConn 500000 14634 ns/op 2371 B/op 24 allocs/op
BenchmarkNetHTTPServerGet10ReqPerConn 1000000 9447 ns/op 2101 B/op 19 allocs/op
BenchmarkNetHTTPServerGet10KReqPerConn 1000000 7939 ns/op 2033 B/op 18 allocs/op
BenchmarkNetHTTPServerGet1ReqPerConn10KClients 300000 30291 ns/op 4589 B/op 31 allocs/op
BenchmarkNetHTTPServerGet2ReqPerConn10KClients 500000 23199 ns/op 3581 B/op 25 allocs/op
BenchmarkNetHTTPServerGet10ReqPerConn10KClients 500000 13270 ns/op 2621 B/op 19 allocs/op
BenchmarkNetHTTPServerGet100ReqPerConn10KClients 500000 11412 ns/op 2119 B/op 18 allocs/op
fasthttp:
$ GOMAXPROCS=1 go test -bench=kServerGet -benchmem -benchtime=5s
PASS
BenchmarkServerGet1ReqPerConn 3000000 2341 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet2ReqPerConn 5000000 1799 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet10ReqPerConn 5000000 1239 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet10KReqPerConn 10000000 1090 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet1ReqPerConn10KClients 3000000 2860 ns/op 4 B/op 0 allocs/op
BenchmarkServerGet2ReqPerConn10KClients 3000000 1992 ns/op 1 B/op 0 allocs/op
BenchmarkServerGet10ReqPerConn10KClients 5000000 1297 ns/op 1 B/op 0 allocs/op
BenchmarkServerGet100ReqPerConn10KClients 10000000 1264 ns/op 9 B/op 0 allocs/op
GOMAXPROCS=4
net/http:
$ GOMAXPROCS=4 go test -bench=NetHTTPServerGet -benchmem -benchtime=5s
PASS
BenchmarkNetHTTPServerGet1ReqPerConn-4 1000000 5545 ns/op 2433 B/op 30 allocs/op
BenchmarkNetHTTPServerGet2ReqPerConn-4 2000000 4147 ns/op 2398 B/op 24 allocs/op
BenchmarkNetHTTPServerGet10ReqPerConn-4 3000000 2628 ns/op 2118 B/op 19 allocs/op
BenchmarkNetHTTPServerGet10KReqPerConn-4 3000000 2304 ns/op 2037 B/op 18 allocs/op
BenchmarkNetHTTPServerGet1ReqPerConn10KClients-4 1000000 7327 ns/op 3561 B/op 30 allocs/op
BenchmarkNetHTTPServerGet2ReqPerConn10KClients-4 1000000 5952 ns/op 3073 B/op 24 allocs/op
BenchmarkNetHTTPServerGet10ReqPerConn10KClients-4 2000000 4345 ns/op 2530 B/op 19 allocs/op
BenchmarkNetHTTPServerGet100ReqPerConn10KClients-4 2000000 3866 ns/op 2132 B/op 18 allocs/op
fasthttp:
$ GOMAXPROCS=4 go test -bench=kServerGet -benchmem -benchtime=5s
PASS
BenchmarkServerGet1ReqPerConn-4 10000000 1053 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet2ReqPerConn-4 10000000 685 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet10ReqPerConn-4 20000000 393 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet10KReqPerConn-4 20000000 338 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet1ReqPerConn10KClients-4 10000000 1033 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet2ReqPerConn10KClients-4 10000000 668 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet10ReqPerConn10KClients-4 20000000 393 ns/op 0 B/op 0 allocs/op
BenchmarkServerGet100ReqPerConn10KClients-4 20000000 384 ns/op 4 B/op 0 allocs/op
In short, fasthttp client is up to 10 times faster than net/http. Below are benchmark results.
GOMAXPROCS=1
net/http:
$ GOMAXPROCS=1 go test -bench='HTTPClient(Do|GetEndToEnd)' -benchmem -benchtime=5s
PASS
BenchmarkNetHTTPClientDoFastServer 500000 17535 ns/op 2624 B/op 38 allocs/op
BenchmarkNetHTTPClientGetEndToEnd 200000 56593 ns/op 5012 B/op 59 allocs/op
fasthttp:
$ GOMAXPROCS=1 go test -bench='kClient(Do|GetEndToEnd)' -benchmem -benchtime=5s
PASS
BenchmarkClientDoFastServer 5000000 1420 ns/op 0 B/op 0 allocs/op
BenchmarkClientGetEndToEnd 500000 17912 ns/op 0 B/op 0 allocs/op
GOMAXPROCS=4
net/http:
$ GOMAXPROCS=4 go test -bench='HTTPClient(Do|GetEndToEnd)' -benchmem -benchtime=5s
PASS
BenchmarkNetHTTPClientDoFastServer-4 1000000 5795 ns/op 2626 B/op 38 allocs/op
BenchmarkNetHTTPClientGetEndToEnd-4 500000 19304 ns/op 5953 B/op 62 allocs/op
fasthttp:
$ GOMAXPROCS=4 go test -bench='kClient(Do|GetEndToEnd)' -benchmem -benchtime=5s
PASS
BenchmarkClientDoFastServer-4 20000000 443 ns/op 0 B/op 0 allocs/op
BenchmarkClientGetEndToEnd-4 1000000 5954 ns/op 0 B/op 0 allocs/op
Unfortunately, fasthttp doesn't provide API identical to net/http. See the FAQ for details. There is net/http -> fasthttp handler converter, but it is advisable writing fasthttp request handlers by hands for gaining all the fasthttp advantages (especially high performance :) ).
Important points:
type MyHandler struct {
foobar string
}
// request handler in net/http style, i.e. method bound to MyHandler struct.
func (h *MyHandler) HandleFastHTTP(ctx *fasthttp.RequestCtx) {
// notice that we may access MyHandler properties here - see h.foobar.
fmt.Fprintf(ctx, "Hello, world! Requested path is %q. Foobar is %q",
ctx.Path(), h.foobar)
}
// request handler in fasthttp style, i.e. just plain function.
func fastHTTPHandler(ctx *fasthttp.RequestCtx) {
fmt.Fprintf(ctx, "Hi there! RequestURI is %q", ctx.RequestURI())
}
// pass bound struct method to fasthttp
myHandler := &MyHandler{
foobar: "foobar",
}
fasthttp.ListenAndServe(":8080", myHandler.HandleFastHTTP)
// pass plain function to fasthttp
fasthttp.ListenAndServe(":8081", fastHTTPHandler)
// net/http request handler
requestHandler := func(w http.ResponseWriter, r *http.Request) {
switch r.URL.Path {
case "/foo":
fooHandler(w, r)
case "/bar":
barHandler(w, r)
default:
http.Error(w, "Unsupported path", http.StatusNotFound)
}
}
// the corresponding fasthttp request handler
requestHandler := func(ctx *fasthttp.RequestCtx) {
switch string(ctx.Path()) {
case "/foo":
fooHandler(ctx)
case "/bar":
barHandler(ctx)
default:
ctx.Error("Unsupported path", fasthttp.StatusNotFound)
}
}
requestHandler := func(ctx *fasthttp.RequestCtx) {
// set some headers and status code first
ctx.SetContentType("foo/bar")
ctx.SetStatusCode(fasthttp.StatusOK)
// then write the first part of body
fmt.Fprintf(ctx, "this is the first part of body\n")
// then set more headers
ctx.Response.Header.Set("Foo-Bar", "baz")
// then write more body
fmt.Fprintf(ctx, "this is the second part of body\n")
// then override already written body
ctx.SetBody([]byte("this is completely new body contents"))
// then update status code
ctx.SetStatusCode(fasthttp.StatusNotFound)
// basically, anything may be updated many times before
// returning from RequestHandler.
//
// Unlike net/http fasthttp doesn't put response to the wire until
// returning from RequestHandler.
}
// net/http code
m := &http.ServeMux{}
m.HandleFunc("/foo", fooHandlerFunc)
m.HandleFunc("/bar", barHandlerFunc)
m.Handle("/baz", bazHandler)
http.ListenAndServe(":80", m)
// the corresponding fasthttp code
m := func(ctx *fasthttp.RequestCtx) {
switch string(ctx.Path()) {
case "/foo":
fooHandlerFunc(ctx)
case "/bar":
barHandlerFunc(ctx)
case "/baz":
bazHandler.HandlerFunc(ctx)
default:
ctx.Error("not found", fasthttp.StatusNotFound)
}
}
fastttp.ListenAndServe(":80", m)
net/http -> fasthttp conversion table:
var (
w http.ResponseWriter
r *http.Request
ctx *fasthttp.RequestCtx
)
VERY IMPORTANT! Fasthttp disallows holding references to RequestCtx or to its' members after returning from RequestHandler. Otherwise data races are inevitable. Carefully inspect all the net/http request handlers converted to fasthttp whether they retain references to RequestCtx or to its' members after returning. RequestCtx provides the following band aids for this case:
Use brilliant tool - race detector - for detecting and eliminating data races in your program. If you detected data race related to fasthttp in your program, then there is high probability you forgot calling TimeoutError before returning from RequestHandler.
[]byte buffers - just reuse them as much
as possible. Fasthttp API design encourages this.go tool pprof --alloc_objects your-program mem.pprof usually gives better
insights for optimization opportunities than go tool pprof your-program cpu.pprof.[]byte and string, since this may result in memory
allocation+copy. Fasthttp API provides functions for both []byte and string -
use these functions instead of converting manually between []byte and string.[]byte buffersThe following tricks are used by fasthttp. Use them in your code too.
var (
// both buffers are uninitialized
dst []byte
src []byte
)
dst = append(dst, src...) // is legal if dst is nil and/or src is nil
copy(dst, src) // is legal if dst is nil and/or src is nil
(string(src) == "") // is true if src is nil
(len(src) == 0) // is true if src is nil
src = src[:0] // works like a charm with nil src
// this for loop doesn't panic if src is nil
for i, ch := range src {
doSomething(i, ch)
}
So throw away nil checks for []byte buffers from you code. For example,
srcLen := 0
if src != nil {
srcLen = len(src)
}
becomes
srcLen := len(src)
[]byte buffer with appenddst = append(dst, "foobar"...)
[]byte buffer may be extended to its' capacity.buf := make([]byte, 100)
a := buf[:10] // len(a) == 10, cap(a) == 100.
b := a[:100] // is valid, since cap(a) == 100.
[]byte bufferstatusCode, body, err := fasthttp.Get(nil, "http://google.com/")
uintBuf := fasthttp.AppendUint(nil, 1234)
Why creating yet another http package instead of optimizing net/http?
Because net/http API limits many optimization opportunities. For example:
map[string][]string. So the server
must parse all the headers, convert them from []byte to string and put
them into the map before calling user-provided request handler.
This all requires unnesessary memory allocations avoided by fasthttp.Why fasthttp API is incompatible with net/http?
Because net/http API limits many optimization opportunities. See the answer above for more details. Also certain net/http API parts are suboptimal for use:
Why fasthttp doesn't support HTTP/2.0 and WebSockets?
There are plans for adding HTTP/2.0 and WebSockets support in the future. In the mean time, third parties may use RequestCtx.Hijack for implementing these goodies. See the first third-party websocket implementation on the top of fasthttp.
Are there known net/http advantages comparing to fasthttp?
Yes:
Which GO versions are supported by fasthttp?
Go1.5+. Older versions won't be supported, since their standard package miss useful functions.
Please provide real benchmark data and sever information
See this issue.
Are there plans to add request routing to fasthttp?
There are no plans to add request routing into fasthttp. I believe request routing must be implemented in a separate package(s) like httprouter. Try fasthttprouter, httprouter fork for fasthttp. See also this issue for more info.
I detected data race in fasthttp!
Cool! File a bug. But before doing this check the following in your code:
FAQs
Package fasthttp provides fast HTTP server and client API. Fasthttp provides the following features: Optimized for speed. Easily handles more than 100K qps and more than 1M concurrent keep-alive connections on modern hardware. Optimized for low memory usage. Easy 'Connection: Upgrade' support via RequestCtx.Hijack. Server supports requests' pipelining. Multiple requests may be read from a single network packet and multiple responses may be sent in a single network packet. This may be useful for highly loaded REST services. Server provides the following anti-DoS limits: The number of concurrent connections. The number of concurrent connections per client IP. The number of requests per connection. Request read timeout. Response write timeout. Maximum request header size. Maximum request body size. Maximum request execution time. Maximum keep-alive connection lifetime. Early filtering out non-GET requests. A lot of additional useful info is exposed to request handler: Server and client address. Per-request logger. Unique request id. Request start time. Connection start time. Request sequence number for the current connection. Client supports automatic retry on idempotent requests' failure. Fasthttp API is designed with the ability to extend existing client and server implementations or to write custom client and server implementations from scratch.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Cyber extortion in the US and Canada hit record levels in 2023, with ransomware attacks surging and median ransom demands skyrocketing, though fewer companies are choosing to pay ransoms.
Security News
Ecma TC39 is meeting this week and has moved key ECMAScript proposals forward, advancing Deferred Import Evaluation, Error.isError(), RegExp Escaping, and Promise.try to the next stages.
Security News
Researchers have demonstrated that teams of LLM agents can exploit zero-day vulnerabilities with a 53% success rate, and the costs of using AI to do so are rapidly becoming more affordable than hiring a human penetration tester.