On 2013-10-22 13:14:06 +0000, James Pike said:
Okay the more I look at this the more convinced I am that the only way
we're gonna get efficient support for websockets and the kind of things
to do with websockets is to change the way vibed works with respect to
websockets.I think using a Fibre per websocket is great, especially when it comes
to reading. However when it comes to writing the data back I think the
"in fibre" write method should schedule the write using a more
traditional libevent architecture based on callbacks. Then other fibres
would be able to transparently write to the websocket.I think this is pretty important... I mean when you consider what web
sockets are for it doesn't make sense to only write from one fibre
there's always going to be a need to push out data from other
fibres/threads and to be able to do that simply and efficiently I think
is pretty important for the adoption of a websocket server.I'm happy to write a patch against vibed if you think this sounds okay?
This is sort of what it's doing anyways. My code spawns a fiber which
is basically a callback in D. It yields a delegate to it's current
executing position to the event loop which resumes it at some later
time.
I don't think 5000 concurrent connections is something to scoff at.
That's around half the efficiency of an 50% of what an IRC server does
without any tuning.
It would be preferable to not have the fiber for the sender thread,
since I already have a fiber-per-channel, but this way different
channels don't block each other from writing to the socket and putting
messages in the MessageQueue should be pretty lightweight.