There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js):

https://github.com/nuald/simple-web-benchmark

I've sent PR to include D benchmark (vibe.d).

I was hoping it could show performance at least not worse than other languages.
But it appears to be slower than Go and even Node.js

Are there any tips to achieve better performance in this test?

Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower.

Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go.

I'm using DMD. Probably, ldc could speed up it a bit.

Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests?

Can it be issue with regex speed?
auto reg = ctRegex!"^/greeting/([a-z]+)$";

Did you try without it?

On Thursday, 21 September 2017 at 08:18:51 UTC, Suliman wrote:
> Can it be issue with regex speed?
> auto reg = ctRegex!"^/greeting/([a-z]+)$";
>
> Did you try without it?

Regex is used for request paths like "/greeting/username" and not used for path "/"

There is no big slowdown caused by regex.
45.6K requests/second with regex vs 46.8K requests/second w/o regex.

Am 21.09.2017 um 10:01 schrieb Vadim Lopatin:
> There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js):
> 
> https://github.com/nuald/simple-web-benchmark
> 
> I've sent PR to include D benchmark (vibe.d).
> 
> I was hoping it could show performance at least not worse than other languages.
> But it appears to be slower than Go and even Node.js
> 
> Are there any tips to achieve better performance in this test?
> 
> Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower.
> 
> Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go.
> 
> I'm using DMD. Probably, ldc could speed up it a bit.
> 
> Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests?

Multi-threading (or multi-process processing) is probably the main reason. The following initialization code should get this on par:

    shared static this()
    {
        runWorkerTaskDist({
            listenHTTP("0.0.0.0:3000", &handleRequest);
        });
    }

The other part is that currently the HTTP server code works rather inefficiently with the new vibe-core implementation, ironically due to the main feature that is meant to speed up vibe-core over the previous implementation: using statically typed structs instead of dynamic interfaces for streams. This currently requires using proxy objects in the HTTP server, which perform their own type of dynamic dispatch, with a higher overhead than using classes/interfaces directly.

But there is a pending redesign of the whole HTTP implementation, which will, among other things, get rid of this and will use statically typed streams throughout the code. It should then be considerably faster than the current code path that uses classes/interfaces.

Finally, there is also a considerable performance bug in vibe-core currently, which I can't fix due to an unresolved Optlink bug: https://github.com/vibe-d/vibe-core/pull/27 (I tried to reduce this with dustmite, took about a week, but of course it reduced to a piece of code that was actually broken - I'll have to redo this with using the MS linker in parallel as a counter test)

>      shared static this()
>      {
>          (...)
>      }

BTW, I'd recommend using

    void main()
    {
        (...)
        runApplication();
    }

instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.

On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>      shared static this()
>>      {
>>          (...)
>>      }
>
> BTW, I'd recommend using
>
>     void main()
>     {
>         (...)
>         runApplication();
>     }
>
> instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.

Thank you!
Trying to use multithreaded mode.

Under windows, best Vibe.d results are equal to results of Go server.
Under linux, Vibe.d is still slower even if there are 4 threads listening.

Results:

OS       lang:config   req/s    comments
=======  ==========    =======  ==========
Linux    go            53K
Linux    D:default     48K      1 thread
Linux    D:libevent    48K      1 thread
Linux    D:libasync    46.5K    4 threads

Windows  go            12K
Windows  D:default     12K      4 threads
Windows  D:libevent    12K      4 threads
Windows  D:libasync    7K       4 threads

Under Linux in default and libevent configurations, I see error messages from 3 of 4 threads - looks like only one thread can process connections.

Failed to listen on 0.0.0.0:3000
Task terminated with uncaught exception: Failed to listen for incoming HTTP connections on any of the supplied interfaces.

Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>>      shared static this()
>>>      {
>>>          (...)
>>>      }
>>
>> BTW, I'd recommend using
>>
>>     void main()
>>     {
>>         (...)
>>         runApplication();
>>     }
>>
>> instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.
> 
> Thank you!
> Trying to use multithreaded mode.
> 
> Under windows, best Vibe.d results are equal to results of Go server.
> Under linux, Vibe.d is still slower even if there are 4 threads listening.
> 
> Results:
> 
> OS       lang:config   req/s    comments
> =======  ==========    =======  ==========
> Linux    go            53K
> Linux    D:default     48K      1 thread
> Linux    D:libevent    48K      1 thread
> Linux    D:libasync    46.5K    4 threads
> 
> Windows  go            12K
> Windows  D:default     12K      4 threads
> Windows  D:libevent    12K      4 threads
> Windows  D:libasync    7K       4 threads
> 
> Under Linux in default and libevent configurations, I see error messages from 3 of 4 threads - looks like only one thread can process connections.
> 
> Failed to listen on 0.0.0.0:3000
> Task terminated with uncaught exception: Failed to listen for incoming HTTP connections on any of the supplied interfaces.
> 
> 

Oh, sorry, I forgot the reusePort option, so that multiple sockets can listen on the same port:

    auto settings = new HTTPServerSettings("0.0.0.0:3000");
    settings.options |= HTTPServerOption.reusePort;
    listenHTTP(settings, &handleRequest);

my results:

OS       lang:config   req/s    comments
=======  ==========    =======  ==========
Linux    go                24K
Linux    D:libevent    27K        4 threads
Linux    D:libasync   26.5K     4 threads

On Thu, Sep 21, 2017 at 2:41 PM, Vadim Lopatin via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>
>>      shared static this()
>>>      {
>>>          (...)
>>>      }
>>>
>>
>> BTW, I'd recommend using
>>
>>     void main()
>>     {
>>         (...)
>>         runApplication();
>>     }
>>
>> instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.
>>
>
> Thank you!
> Trying to use multithreaded mode.
>
> Under windows, best Vibe.d results are equal to results of Go server. Under linux, Vibe.d is still slower even if there are 4 threads listening.
>
> Results:
>
> OS       lang:config   req/s    comments
> =======  ==========    =======  ==========
> Linux    go            53K
> Linux    D:default     48K      1 thread
> Linux    D:libevent    48K      1 thread
> Linux    D:libasync    46.5K    4 threads
>
> Windows  go            12K
> Windows  D:default     12K      4 threads
> Windows  D:libevent    12K      4 threads
> Windows  D:libasync    7K       4 threads
>
> Under Linux in default and libevent configurations, I see error messages from 3 of 4 threads - looks like only one thread can process connections.
>
> Failed to listen on 0.0.0.0:3000
> Task terminated with uncaught exception: Failed to listen for incoming
> HTTP connections on any of the supplied interfaces.
>
>
>

my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj

On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
>
>> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>
>>>      shared static this()
>>>>      {
>>>>          (...)
>>>>      }
>>>>
>>>
>>> BTW, I'd recommend using
>>>
>>>     void main()
>>>     {
>>>         (...)
>>>         runApplication();
>>>     }
>>>
>>> instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.
>>>
>>
>> Thank you!
>> Trying to use multithreaded mode.
>>
>> Under windows, best Vibe.d results are equal to results of Go server. Under linux, Vibe.d is still slower even if there are 4 threads listening.
>>
>> Results:
>>
>> OS       lang:config   req/s    comments
>> =======  ==========    =======  ==========
>> Linux    go            53K
>> Linux    D:default     48K      1 thread
>> Linux    D:libevent    48K      1 thread
>> Linux    D:libasync    46.5K    4 threads
>>
>> Windows  go            12K
>> Windows  D:default     12K      4 threads
>> Windows  D:libevent    12K      4 threads
>> Windows  D:libasync    7K       4 threads
>>
>> Under Linux in default and libevent configurations, I see error messages from 3 of 4 threads - looks like only one thread can process connections.
>>
>> Failed to listen on 0.0.0.0:3000
>> Task terminated with uncaught exception: Failed to listen for incoming
>> HTTP connections on any of the supplied interfaces.
>>
>>
>>
> Oh, sorry, I forgot the reusePort option, so that multiple sockets can listen on the same port:
>
>     auto settings = new HTTPServerSettings("0.0.0.0:3000");
>     settings.options |= HTTPServerOption.reusePort;
>     listenHTTP(settings, &handleRequest);
>

wrong version, this is my letest version: https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR

On Thu, Sep 21, 2017 at 3:01 PM, Daniel Kozak <kozzi11@gmail.com> wrote:

> my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
>
> On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
>>
>>> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>>
>>>>      shared static this()
>>>>>      {
>>>>>          (...)
>>>>>      }
>>>>>
>>>>
>>>> BTW, I'd recommend using
>>>>
>>>>     void main()
>>>>     {
>>>>         (...)
>>>>         runApplication();
>>>>     }
>>>>
>>>> instead and dropping the VibeDefaultMain version in the package recipe. The old approach is planned to be faded out slowly, because it requires some special DUB support that would be nice to see gone at some point.
>>>>
>>>
>>> Thank you!
>>> Trying to use multithreaded mode.
>>>
>>> Under windows, best Vibe.d results are equal to results of Go server. Under linux, Vibe.d is still slower even if there are 4 threads listening.
>>>
>>> Results:
>>>
>>> OS       lang:config   req/s    comments
>>> =======  ==========    =======  ==========
>>> Linux    go            53K
>>> Linux    D:default     48K      1 thread
>>> Linux    D:libevent    48K      1 thread
>>> Linux    D:libasync    46.5K    4 threads
>>>
>>> Windows  go            12K
>>> Windows  D:default     12K      4 threads
>>> Windows  D:libevent    12K      4 threads
>>> Windows  D:libasync    7K       4 threads
>>>
>>> Under Linux in default and libevent configurations, I see error messages from 3 of 4 threads - looks like only one thread can process connections.
>>>
>>> Failed to listen on 0.0.0.0:3000
>>> Task terminated with uncaught exception: Failed to listen for incoming
>>> HTTP connections on any of the supplied interfaces.
>>>
>>>
>>>
>> Oh, sorry, I forgot the reusePort option, so that multiple sockets can listen on the same port:
>>
>>     auto settings = new HTTPServerSettings("0.0.0.0:3000");
>>     settings.options |= HTTPServerOption.reusePort;
>>     listenHTTP(settings, &handleRequest);
>>
>
>