Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig]

Am 22.09.2017 um 09:45 schrieb Vadim Lopatin:
> On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote:
>> On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
>>> It does. But Golang uses them, too. Goroutines.
>>
>> Indeed. I'm reading about them right now, and they seem to be 
>> "multiplexed". I wonder if Vibe.d does something similar.
>>
>> The fact that you've observed lower CPU usage by the D version makes 
>> me think some kind of scheduling or thread-priority issue is the cause.
> 
> Fibers are being switched by waiting for signals/events.
> Waiting blocks thread.
> Timer should affect only non-blocked threads switching IMHO.

What's was the last status? Could you observe any meaningful thread scaling?

I tested on a 32-core machine a while back and could observe the 
performance rising almost linearly when increasing the number of cores 
(as it should). The effect is obviously smaller on a dual-core system 
where the benchmark application runs on the same system, but even there 
it was well visible.

If the multi-threaded version doesn't show 100% CPU usage, that would 
mean that some kind of thread-blocking is happening - GC collections or 
lock contention would be the likely candidates for that. The latter 
shouldn't happen anymore, as everything except for the logger should be 
thread-local in the latest version.

BTW, I ran Daniel's version on my dual-core notebook against wrk (Linux) 
and got 75kreq/s when using runWorkerTask and ~56kreq/s when using just 
a single thread, which is about what I would expect, considering that 
wrk ran on the same machine.