48

A fasthttp based server is up to 10 times faster than net/http.

Which implementation details make fasthttp so much faster? Moreover, how does it manage incoming requests better than net/http?

Alois Mahdal
  • 10,763
  • 7
  • 51
  • 69
Amit Verma
  • 749
  • 2
  • 7
  • 17
  • 6
    Main reason: fasthttp is **not** a full implementation of HTTP. fasthttp might be good enough for most HTTP stuff, but not for everything. – Volker Jan 13 '17 at 11:56
  • 2
    @Volker...Can you tell what are the things that have been left out in fasthttp – Amit Verma Jan 13 '17 at 12:16
  • 3
    For starters, no http/2 support https://github.com/valyala/fasthttp/issues/144 – nishanthshanmugham Jan 13 '17 at 20:59
  • 2
    I test a benchmark, net/http vs fasthttp, [result](https://github.com/nurmohammed840/web-benchmark#go-v116-linux) is very interesting – Nur May 24 '21 at 00:25
  • A big reason is that the benchmarks shown use *http1 pipelining*, a feature that is was basically never implemented, and fasthttp supports while net/http does not. – Ibraheem Ahmed Oct 31 '21 at 02:49

1 Answers1

46

The article "http implementation fasthttp in golang" from husobee mentions:

Well, this is a much better implementation for several reasons:

  1. The worker pool model is a zero allocation model, as the workers are already initialized and are ready to serve, whereas in the stdlib implementation the go c.serve() has to allocate memory for the goroutine.
  2. The worker pool model is easier to tune, as you can increase/decrease the buffer size of the number of work units you are able to accept, versus the fire and and forget model in the stdlib
  3. The worker pool model allows for handlers to be more connected with the server through channel communications, if the server needs to shutdown for example, it would be able to more easily communicate with the workers than in the stdlib implementation
  4. The handler function definition signature is better, as it takes in only a context which includes both the request and writer needed by the handler. this is HUGELY better than the standard library, as all you get from the stdlib is a request and response writer… The work in go1.7 to include context within the request is pretty much a hack to give people what they really want (context) without breaking anyone.

Overall it is just better to write a server with a worker pool model for serving requests, as opposed to just spawning a “thread” per request, with no way of throttling out of the box.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 11
    @amit-verma, still, please take into account that one of the reasons this package is faster is the ["standards are for losers" attitude of its author](https://groups.google.com/d/msg/golang-nuts/OaQu4QezAr0/AtrwY00LBgAJ). Hence if I were you, I'd start with `net/http` to be on the safe side: folks which are into CS/IT *do* have a natural tendency to overoptimize beause, well, we all like our systems to be "the best". Unfortunately, in real world *maintainability* most of the time trumps raw speed. – kostix Jan 13 '17 at 06:45
  • 8
    @amit-verma, Well, unless you're Facebook and can, for instance, offer youserlf to divulge into projects with insane maintainability efforts like making PHP actually work for their workloads ;-) What I mean, `net/http` is battle-tested and standards compliant and has the core Go team behind it. So do you really need `fasthttp`'s raw speed for your project *now?* Do you have bottlenecks? Have you profiled it and ruled out the usual culprits (like ineffective allocations / lots of pointers to pointers to pointers etc)? – kostix Jan 13 '17 at 06:50