Added go-fasthttp benchmark

[heppu]

Go benchmark using fasthttp which was created for same purpose as japronto was.

[squeaky-pl]

Cool, fasthttp was mentioned several times on reddit and it is supposedly much faster than stdlib. I wish I knew about it before.

[heppu]

Ok this is interesting. On my machine the fasthttp was over 5x faster than go's own http library. The japronto was 1.17x faster than the fasthttp but I'm not sure if the python setup was correct so I would like you to confirm that test. =)

[heppu]

If I don't limit GOMAXPROCS like no one in real life use case would the fasthttp version is actually little faster than the japronto on my laptop.

[frnkvieira]

@heppu are you using multiple workers with japronto also ? I would like too see a "real" world battle with unlimited cores on GO and Japronto...

[heppu]

@jeanfrancisroy I'm not that familiar with python that I would now best way to setup multiple workers with japronto. I come from go world so we get the full power by default 😉
If you can tell me how to do that I can test it.

[heppu]

I would also like mention that Transfer/sec rate was 2x greater with fasthttp than with japronto.

[frnkvieira]

@heppu Not sure if this is indeed the best way but it gets a lot faster on my machine. (Full CPU cores usage)

import multiprocessing
import japronto
import ujson


def home(request):
    return request.Response(ujson.dumps({'Hello': 1}))


if __name__ == '__main__':
    app = japronto.Application()
    app.router.add_route('/', home)
    app.run(worker_num=multiprocessing.cpu_count())

[heppu]

There seeems to be quite lot variance in the results so these are the median records out of ten runs:

Japronto 1 worker
Requests/sec: 536297.90
Transfer/sec: 47.05MB

Japronto 4 workers
Requests/sec: 614251.03
Transfer/sec: 53.89MB

fasthttp GOMAXPROCS=1
Requests/sec: 444446.32
Transfer/sec: 62.31MB

fasthttp GOMAXPROCS=4
Requests/sec: 522654.64
Transfer/sec: 73.27MB

[squeaky-pl]

@heppu you can have some luck with minimizing variance by switching your CPU governor to fixed frequency and sending SIGSTOP to all the noisy processes (usually browsers, spotify etc).You can also completely isolate CPUs by tweaking your kernel boot parameters so the OS doesnt use them and manually placing workers on those CPUs. You might also want to disable Intel Turbo Boost - there is a bug in the kernel that makes it jitter CPUs in a weird way

[heppu]

@squeaky-pl I think I leave that for the next person, just wanted to see how these compare roughly and looks like fasthttp comes pretty close to japronto but still not quite there =) Great work!

[squeaky-pl]

@heppu thanks for your time as well. I am gonna include fasthttp it in the next benchmarking round. I know many areas in Japronto that could be faster, it's just refactoring C is not fun at all and it's very very fragile. I might actually invetigate rewriting parts of Japronto in Rust.

[dom3k]

It should be noted that the response header golang fasthttp / stdlib is two times higher because it contains the current date. By the way good job :)

[rebootcode]

@squeaky-pl - can you update the benchmark chat on the homepage with fast HTTP benchmark too. It is very misleading at the moment.