Apart from some fixes vibe.d received some performance tuning and multi-threaded request processing (thanks to Dicebot for digging up some documents of how Nginx does this). The result is a nice increase in performance (~48 kreq/s vs. 25 kreq/s top) and >10k parallel connections can now easily be handled, at least on 64-bit systems (the needed _virtual_ memory can grow quite large, but real memory use stays low).

DUB has received a number of fixes for bugs that were introduced in the previous release and some smaller enhancements. It now also has Debian packages maintained by Jordi Sayol available.


vibe.d change log and download:
  http://vibed.org/blog/posts/vibe-release-0.7.14
  http://vibed.org/download

DUB change log:
  https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
  http://registry.vibed.org/download

AUR package https://aur.archlinux.org/packages/vibed has been updated.

On Friday, 22 March 2013 at 08:46:23 UTC, Sönke Ludwig wrote:
> Apart from some fixes vibe.d received some performance tuning and
> multi-threaded request processing (thanks to Dicebot for digging up some
> documents of how Nginx does this).

Awesome! I had hoped you would add multi-threaded processing. I'm looking forward to playing with this.

Graham


> The result is a nice increase in
> performance (~48 kreq/s vs. 25 kreq/s top) and >10k parallel connections
> can now easily be handled, at least on 64-bit systems (the needed
> _virtual_ memory can grow quite large, but real memory use stays low).
>
> DUB has received a number of fixes for bugs that were introduced in the
> previous release and some smaller enhancements. It now also has Debian
> packages maintained by Jordi Sayol available.
>
>
> vibe.d change log and download:
>   http://vibed.org/blog/posts/vibe-release-0.7.14
>   http://vibed.org/download
>
> DUB change log:
>   https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
>   http://registry.vibed.org/download

Just retested using weighttp instead of ab and now got up to 90 kreq/s with "weighttp -c 100 -n 100000 -k http://127.0.0.1/empty".

Still way to go compared to what others claim (e.g. vert.x or gwan) but since adding just some DB queries, file I/O or dynamic memory allocations already destroy the numbers, this is really just a very artificial setup for 99% of the applications anyway. Quite important for marketing, though, I guess.

On Friday, 22 March 2013 at 13:57:52 UTC, Graham Fawcett wrote:
> On Friday, 22 March 2013 at 08:46:23 UTC, Sönke Ludwig wrote:
>> Apart from some fixes vibe.d received some performance tuning and
>> multi-threaded request processing (thanks to Dicebot for digging up some
>> documents of how Nginx does this).
>
> Awesome! I had hoped you would add multi-threaded processing. I'm looking forward to playing with this.

How does it work? I added this to HttpServerSettings:
options |= HttpServerOption.distribute

But it doesn't seem to use more threads.

On Friday, 22 March 2013 at 14:21:47 UTC, simendsjo wrote:
> On Friday, 22 March 2013 at 13:57:52 UTC, Graham Fawcett wrote:
>> On Friday, 22 March 2013 at 08:46:23 UTC, Sönke Ludwig wrote:
>>> Apart from some fixes vibe.d received some performance tuning and
>>> multi-threaded request processing (thanks to Dicebot for digging up some
>>> documents of how Nginx does this).
>>
>> Awesome! I had hoped you would add multi-threaded processing. I'm looking forward to playing with this.
>
> How does it work? I added this to HttpServerSettings:
> options |= HttpServerOption.distribute
>
> But it doesn't seem to use more threads.

Combining that with http://vibed.org/api/vibe.core.core/enableWorkerThreads seems to do the trick for me (according to top output), but don't know if it is the supposed way.

New Debian packages available at:

https://code.google.com/p/d-apt/

-- 
Jordi Sayol

I have done a few performance tests and I am afraid I do not like where it gets. Not enough data for public review has been gathered yet, so I have sent my concerns via e-mail.

But to sum up short, feels like GC issues start to hit hard at higher concurrency levels.

Am 22.03.2013 15:51, schrieb Dicebot:
> On Friday, 22 March 2013 at 14:21:47 UTC, simendsjo wrote:
>> On Friday, 22 March 2013 at 13:57:52 UTC, Graham Fawcett wrote:
>>> On Friday, 22 March 2013 at 08:46:23 UTC, Sönke Ludwig wrote:
>>>> Apart from some fixes vibe.d received some performance tuning and
>>>> multi-threaded request processing (thanks to Dicebot for digging up
>>>> some
>>>> documents of how Nginx does this).
>>>
>>> Awesome! I had hoped you would add multi-threaded processing. I'm looking forward to playing with this.
>>
>> How does it work? I added this to HttpServerSettings: options |= HttpServerOption.distribute
>>
>> But it doesn't seem to use more threads.
> 
> Combining that with http://vibed.org/api/vibe.core.core/enableWorkerThreads seems to do the trick for me (according to top output), but don't know if it is the supposed way.

Yes that's the correct way. To get full performance, -version=VibeManualMemoryManagement is also needed, as every small bit of GC usage has a big impact on performance (and due to the stop-the-world nature it also has an even higher impact on multi-threaded performance).