Performance issue

[wsantos]

I was searching a framework to make the code more clean, But for me this added to much overhead

• julienschmidt/httprouter / recovery middleware / mgo

~ ❯❯❯ wrk -t 4 -c 16 -d 30s --latency http://127.0.0.1:8080/mails
Running 30s test @ http://127.0.0.1:8080/mails
  4 threads and 16 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   359.23us  183.29us   6.48ms   86.71%
    Req/Sec    11.20k     1.76k   14.48k    76.64%
  Latency Distribution
     50%  307.00us
     75%  375.00us
     90%  581.00us
     99%    1.06ms
  1341064 requests in 30.10s, 327.41MB read
  Non-2xx or 3xx responses: 1341064
Requests/sec:  44552.97
Transfer/sec:     10.88MB

• gin / without any middleware

Running 30s test @ http://127.0.0.1:8080/mails
  4 threads and 16 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.22ms  567.58us   8.39ms   75.66%
    Req/Sec     1.81k   300.50     2.45k    71.08%
  Latency Distribution
     50%    2.11ms
     75%    2.48ms
     90%    2.92ms
     99%    4.14ms
  216235 requests in 30.01s, 310.77MB read
Requests/sec:   7205.48
Transfer/sec:     10.36MB

• Command used to start the server: GOMAXPROCS=8 go run server.go

1. Why is gin hitting that much the performance
2. there is anything that I can do to fix it or provide more information ? I really want to use gin.

regards.

[manucorporat]

@wsantos Can I see some of the code? are you using New()?

Also, there was an important performance regression this week, it was already fixed: #329

can you verify you are using the last version (HEAD of remote master).

go get -u github.com/gin-gonic/gin

[manucorporat]

Anyway, the tests does not looks the same:

httpRouter was returning non-200

 1341064 requests in 30.10s, 327.41MB read
  Non-2xx or 3xx responses: 1341064

while Gin, was responding good 200 responses...

[manucorporat]

Also, I can not see the code, but a quick analytics shows that the transfer speed is almost the same: 10.88MB vs 10.36MB. while the number of requests is completely different. That means: you are serving completely different content.

Your performance analysis does not look good.

1. Update Gin
2. Fix your tests (what is httprouter serving?=
3. Run the benchmarks again.

[manucorporat]

@wsantos
Gin without any middleware should even faster that HttpRouter, or at least the same performance.
https://github.com/gin-gonic/gin#benchmarks

BenchmarkGin_GithubAll     30000         50991 ns/op           0 B/op          0 allocs/op
BenchmarkHttpRouter_GithubAll      20000         63506 ns/op       13792 B/op        167 allocs/op

otherwise they is a problem that should be fixed!!

[nazwa]

Keep in mind the dev / production mode that everyone keeps forgetting about :)

[wsantos]

@manucorporat here it is the corrected benchmark for julienschmidt/httprouter / recovery middleware / mgo, I forgot to add the Accept Header, so that was erring every request and just returning 406.

Running 30s test @ http://127.0.0.1:8080/mails
  4 threads and 16 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.88ms  724.75us  16.50ms   69.94%
    Req/Sec     1.39k    62.98     1.53k    81.42%
  Latency Distribution
     50%    2.88ms
     75%    3.34ms
     90%    3.76ms
     99%    4.66ms
  166481 requests in 30.02s, 236.88MB read
Requests/sec:   5546.48
Transfer/sec:      7.89MB

Gin is faster than httprouter without any middleware, thank you @manucorporat.

[wsantos]

Awesome work btw ! I can't wait to see the Zero Allocation Router.

[manucorporat]

hahaha nice!! also! @nazwa gave you a good advice. switch to release mode when deploying in production. it can be done programatically or through the environment variable (GIN_MODE)

[manucorporat]

@wsantos The Zero Allocation Router is already working in master!

BenchmarkGin_GithubAll     30000         50991 ns/op           0 B/op          0 allocs/op
BenchmarkHttpRouter_GithubAll      20000         63506 ns/op       13792 B/op        167 allocs/op

see the number of allocations!

in practice, it will still allocate some memory because the sync.pools are discarted in each garbage collection. But do not worry too much!