On Wednesday, 5 September 2012 at 14:22:50 UTC, Eldar
Insafutdinov wrote:

On Friday, 13 July 2012 at 10:51:11 UTC, Sönke Ludwig wrote:

Am 12.06.2012 19:38, schrieb Sönke Ludwig:

Am 12.06.2012 09:01, schrieb Nick Sabalausky:

Just a thought I had: Would it be reasonable for vibe.d to
tell the GC
to run a collection cycle whenever vibe.d detects it's a
good time to do
so? (For example, when there's no traffic for a certain
amount of time.)
Or does vibe.d already do something like this?

It doesn't do this right now but that would be an idea and
should be
relatively easy to do using a timer once there is support for
an
onIdle() callback, which I have lying around somwhere already
(I'll
check this in when I get some time). Would be interesting to
test how
efficient this is for reducing delays in practice.

I've just added this as an optional feature. With
DFLAGS="-version=VibeIdleCollect", it should now run a GC
collection whenever there was no activity for 2 seconds.

I've done a some simple Pong benchmark(serving "Hello world")
of the Vibe server with 1 million connections and 100
simultaneous: 

ab -n 1000000 -c 100

And while the performance was very good, the memory usage grew
to numbers of few hundred megabytes(the highest was 600Mb)
without any attempt to recycle memory. NodeJS for example kept
it around 30Mb under the same load. This case is probably not
realistic for low load scenarios, but if we want to sell the
project for high load we better have a good GC. But I
understand that this is a long standing problem in D...

Ok, I've done some more tests. This time I was stress testing the
server built with DFLAGS="-version=VibeIdleCollect" . There was
one invocation of GC.collect() before the benchmark started(the
same one as in my previous post). During the stress test
GC.collect() wasn't called from that handler which is expected as
the server wasn't idling. The memory usage grew to 380Mb. However
when the benchmark finished there was GC collection invoked, but
the memory usage stayed at the same level. This suggests there is
a leak somewhere. The server was pretty simple:
http://pastie.org/4670356