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