Am 07.03.2014 23:29, schrieb Sean Kelly:
On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
On Fri, 2014-03-07 at 16:53 +0000, Sean Kelly wrote:
[…]
68K connections is nothing. I'll start getting interested when his
benchmarks are 200K+. Event-based systems in C can handle millions
of concurrent connections if implemented properly. I'd like to
believe vibe.d can approach this as well.
There used to be a 100k problem, i.e maintaining more than 100k active,
that means regularly causing traffic, not just being dormant for a few
centuries, but so many frameworks can now support that , that it has
become a non-metric. I don't know if Spring, JavaEE, can handle this but
on the JVM Vert.x certainly, I suspect Node.js can as well. Vert.x is
caliming to be able to handle millions of active connections.
I suspect it is now at the stage that the OS is the bottle neck not the
language of the framework.
I think the biggest issue at very large number of connections is memory
use. In fact, I don't expect even vibe.d to scale beyond a few hundred K
if it allocates a fiber per connection. It would have to use a free list
of fibers and make a top-level read effectively release the current
fiber into the free list. Scaling at this level in C generally meant
retaining little to no state per connection basically by necessity.
A free list is already used for fibers actually. Each fiber can be
reused for any number of "tasks". This is also why `Fiber` as a type
doesn't occur in the public API, but rather the `Task` struct, which
internally points to a fiber + a task ID.
But since the memory pages of a fiber's stack are allocated lazily, at
least on a 64-bit OS, where address space is not an issue, you can
actually scale to very high numbers with a decent amount of RAM.
Certainly you don't need to have the amount of RAM that the typical
dedicated server for such tasks would have.
Having said that, it may be an interesting idea to offer a callback
based overload of waitForData(), so that you can do something like this:
listenTCP(port, &onConnection);
void onConnection(TCPConnection conn)
{
conn.waitForData(&onData);
// return (exits the task and puts the fiber
// into the free list)
}
void onData(TCPConnection conn)
{
// onData gets called as a new task, so that no fiber is
// occupied between the wait and the read calls
conn.read(...);
}
