On Thursday, 31 December 2015 at 08:51:31 UTC, yawniek wrote:
On Thursday, 31 December 2015 at 08:23:26 UTC, Laeeth Isharc
wrote:
Isn't there a decent chance the bottleneck is vibe.d's JSON
implementation rather than the framework as such ? We know
from Atila's MQTT project that vibe.D can be significantly
faster than Go, and we also know that its JSON implementation
isn't that fast. Replacing with FastJSON might be interesting.
Sadly I don't have time to do that myself.
this is not the same benchmark discussed elsewhere, this one is
a simple echo thing.
no json. it just states that there is some overhead around on
various layers.
so its testimony is very limited.
from a slightly more distant view you can thus argue that 50k
rps vs 150k rps basically just means that the framework will
most probably not be your bottle neck.
none the less, getting ahead in the benchmarks would help to
attract people who are then pleasantly surprised how easy it is
to make full blown services with vibe.
the libasync problem seem seems to be because of TCP_NODELAY
not being deactivated for local connection.
That would be the other way around. TCP_NODELAY is not enabled in
the local connection, which makes a ~20-30ms difference per
request on keep-alive connections and is the bottleneck in this
case. Enabling it makes the library competitive in these
benchmarks.
