V Thu, 31 Dec 2015 12:26:12 +0000 yawniek via Digitalmars-d <[email protected]> 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);
