vibe.d benchmarks

Daniel Kozak via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 31 04:44:37 PST 2015


V Thu, 31 Dec 2015 12:26:12 +0000
yawniek via Digitalmars-d <digitalmars-d at puremagic.com> napsáno:

> On Thursday, 31 December 2015 at 12:09:30 UTC, Etienne Cimon 
> wrote:
> > On Thursday, 31 December 2015 at 08:51:31 UTC, yawniek wrote:  
> >> 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.  
> 
> obvious typo and thanks for investigating etienne.
> 
> @daniel: i made similar results over the network.
> i want to redo them with a more optimized setup though. my wrk 
> server was too weak.
> 
> the local results are still relevant as its a common setup to 
> have nginx distribute to a few vibe instances locally.

One thing I forgot to mention I have to modify few things

vibe.d has (probably) bug it use threadPerCPU instead of corePerCPU in
setupWorkerThreads, here is a commit which make possible to setup it by
hand.

https://github.com/rejectedsoftware/vibe.d/commit/f946c3a840eab4ef5f7b98906a6eb143509e1447

(I just modify vibe.d code to use all my 4 cores and it helps a lot)

To use more threads it must be setup with distribute option:

settings.options |= HTTPServerOption.distribute;
//setupWorkerThreads(4); // works with master
listenHTTP(settings, &hello);





More information about the Digitalmars-d mailing list