On Mon, 06 Apr 2015 19:00:02 GMT, Sönke Ludwig wrote:

On Mon, 06 Apr 2015 18:06:59 GMT, Dato wrote:

On Mon, 06 Apr 2015 14:43:52 +0200, Sönke Ludwig wrote:

Am 05.04.2015 um 18:07 schrieb Dato:

(...)

Thanks, nice to now :). Also before we start diving deep in vibe, is there any pitfall, drawbacks we should be aware of? Is vibe.d stable enough to run a web server 24/7? is there any production system built on it? how does it do within heavy loaded environment?

There are several production systems running with vibe.d, so this is
certainly doable. However, one thing to be aware of is that it currently
still lacks certain kinds of DoS countermeasures, so if you want to use
it for a large-scale public service, there should be some kind of
proxy/load balancer system that provides those.

It scales well for high loads, but you have to be careful with using a
lot of garbage collected memory, because the garbage collector will stop
the whole process during collection runs. Generally it's a good idea to
use some form of reference counting for dynamic memory allocations (e.g.
vibe.utils.memory.FreeListRef or std.typecons.RefCounted).

I see. I guess those classes are similar to smart pointers. Just to make sure, is D's GC so bad? I can use RefCounted and FreeListRef, but what about vibe's internal implementation? We are going to have several thousand small requests per second and GC should also be an issue for vibe's internal allocations/calls no? Currently, our C# implementation handles ~7k requests per second without caching on a single server. According to our (dirty work) benchmarks, the system should perform at least 35% better when ported to GDC, but we didn't check GC to be honest...

Thanks again :)

The issues with the GC start to become apparent when you get close to the maximum number of requests that the machine can handle. It's the pause times that occur during the collection that can result in delayed requests or dropped connections. This is something that basically happens for most GC implementations more or less and D's GC isn't that bad per se, but others, such as the Java one are still a lot better.

Vibe.d has a mode where the basic request processing doesn't perform any GC allocations (enabled by putting "versions": ["VibeManualMemoryManagement"] in the project's dub.json), so it's possible to create applications that don't use the GC during request processing at all. However, a number of DB operations do still perform GC allocations currently.

But I guess you'll just have to make a simple benchmark to see if the GC is really an issue at all. It depends a lot on the application, but a simple application that doesn't have a database as the bottleneck can easily handle more than 10k requests per second on mediocre hardware, even with the GC enabled.

In an old benchmark (simple HTTP reply with no dynamic computations) I got about 70k requests per second on an AMD Phenom2 quad core with manual memory management and using multi-core processing. I'd have to rerun that benchmark now to be sure that those numbers still hold, but that's about the maximum that you can currently expect for that kind of CPU.

Wonderful. Thank you for your informative reply. I guess, we will port one game to D and see how it works.

Thanks again :)