Go http server slow benchmark performance

Question

I was trying to find the maximum throughput of a go webserver. I ran simplewebserver on a 8 core machine(Intel Xeon 2.5 Mhz) and ran wrk tool on a different 8 core machine. Iperf command shows around 8-10Gbps between these machines . Initially, I made a mistake by using apache ab tool that gave only 16k requests/second. The problem was same as link. Now when I switched to wrk tool, I am getting around 90k requests per second and ~ 11MB/sec.

on the first 8 core machine, I ran simplewebserver.go

package main

import (
   "io"
    "net/http"
    "runtime"
)

func hello(w http.ResponseWriter, r *http.Request) {
    io.WriteString(w, "Hello world!")
}

 func main() {
    runtime.GOMAXPROCS(8)
    http.HandleFunc("/", hello)
    http.ListenAndServe(":8000", nil)
 }

On a different 8 core machine, i ran

 ./wrk -t8 -c1000 -d10s http://10.0.0.6:8000/

Result:

Running 10s test @ http://10.0.0.6:8000/
8 threads and 1000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
Latency    42.65ms  114.89ms   1.96s    91.33%
Req/Sec    11.54k     3.01k   25.10k    74.88%
923158 requests in 10.10s, 113.57MB read
Socket errors: connect 0, read 0, write 0, timeout 20
Requests/sec:  91415.11
Transfer/sec:     11.25MB

Can i say that I have reached maximum throughput of a golang web server? I am getting 11 MB/sec which looks quite small for the basic program. If I run the wrk tool on www.google.com page, I am getting around 200 MB/sec. Even for larger complex computing systems like kafka(java server), the benchmark results get more than 70 MB/sec(https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines). How can a golang server handle extreme workloads of millions of requests per second(more than 100MB/sec minimum)? Am I wrong in any assumptions?

UPDATE:

I ran the same program on a 16 core machine with the same specs. I changed the maxprocs to 16 and results went higher to 120k requests/sec. I feel that I have the reached the maximum of golang http server and hence I am not finding any significant increment in the requests/sec.

Solution 1

"premature optimization is the root of all evil"1

I would suggest building something for your use case and then attempting to optimize. It is difficult to build a good benchmark that tests what you want so make sure you are testing what you want and not something like the speed of your router.

Solution 2

Golang net/http is rather slow. If the goal is to maximize the requests rate there are other implementations. For example https://github.com/valyala/fasthttp In my tests fasthttp doubles the query rate. My test is a short request and short reply.

The library comes with limitations, like no HTTP/2 support. If you need HTTP for REST API and you are not looking for interoperability fasthttp will fit nicely

Comments

[JimB]

www.google.com serves more than just "hello". Throughput and request rate are hardly related.

[Josh Wilson]

To elaborate on that, I'd imagine you'd get a much higher throughput if your hello world function returned the contents of a large file on disk.

[Josh Wilson]

I honestly don't know how well golang preforms in comparison to other languages, but you are comparing an http server to one that takes in log messages. There is probably a bit of overhead parsing the http request and encoding the response. You'll also have a little overhead on the flexibility of the framework. If you want to test pure speed, try making something like coderwall.com/p/wohavg/creating-a-simple-tcp-server-in-go and then add pooling so you don't reallocate new buffers. You may never get quite to the performance of kafka, but at that would be a good comparison.

[Josh Wilson]

And there's a reasonable chance when you hit google.com every single one of your requests is going to a different server, so again a pretty bad comparison.

[RickyA]

Latency is not bandwidth. In fact the only correlation is that when you consume all your bandwidth, your latency will rise. Latency normally stems from other things like the type of networking (wireless == crap) topology of network, load on the servers themself (not io). I really cannot tell you something meaningful here.