search

olliNiinivaara / GuildenStern

Modular multithreading HTTP/1.1 + WebSocket server framework
MIT License
80 stars 7 forks source link

Low req/s number when compile with --threads:on #1

Closed Willyboar closed 4 years ago

Willyboar commented 4 years ago

After a small discussion in the discord nim server, we tried to benchmark Guildenstern. The results are in this gist:

Results

olliNiinivaara commented 4 years ago

Guildenstern is fast in principle, Weave is fast in principle, but we are still experimenting on how to make them fast together... Thanks to mssr. mratsim, this problem (see: https://github.com/mratsim/weave/issues/155) now has a fix. Reinstall and overwrite both Weave and Guildenstern masters.

On more general level, there seems to be no real effect between running httpbeast with 12 or 32 threads, hinting that you may not be benchmarking what you think you are benchmarking (the http server is not the bottleneck).

Also note that httpbeast is developed just to win these kind of naïve benchmarks (it takes control of all your threads). I assume that you should see Weave and Guildenstern shine in benchmarks where there's a lot variation in request frequency and generating response needs a lot of CPU power like producing some raytracing image...

olliNiinivaara commented 4 years ago

Switched Weave to threadpool for now. Threadpool performance is in same ballpark with Weave (with trivial benchmarks, definitely slower than single-threaded). This confirms that no matter how the multithreading is implemented, when there's very little real work to do, the overhead of thread switching will dominate over benefits from parallelism.

I'd like to see benchmark results where serving a http request requires more than few milliseconds of CPU time.