I have been building Photon[1] scheduler library with the aim to
build high performance servers but since we are already have
vibe.d and everybody is using it might as well try to speed it
up. Thus vibe.d-light idea was born - port vibe.d framework on
top of photon.
So in the last couple of weeks I've been porting vibe-core,
vibe-stream, vibe-inet and vibe-http to:
a) work with Photon instead of eventcore
b) speed things up as I go, since I like fast things
The end result is that running bench-http-server from vibe-http
examples I get 1.6M rps with my version vs 243k rps on vanila
running on 48 rather weak cores.
Ofc I want people to try it and see how it works in terms of
correctness and speed on more complex projects:
https://code.dlang.org/packages/vibe-d-light
https://github.com/DmitryOlshansky/vibe.d
Though most of work goes on in deps:
https://github.com/DmitryOlshansky/vibe-http
https://github.com/DmitryOlshansky/vibe-core
See also Photon the machinery behind it all:
https://github.com/DmitryOlshansky/photon
Warning - this is likely Linux only at the moment, though I
expect MacOS to also work.
Key differences so far:
1. photon powered *-light versions always run multi-threaded
utilizing whatever number of cores you gave them with e.g.
taskset or all of them by default. No need to muck around with
setting up multiple event loops and if you did - don't worry
it'll still do the right thing.
2. There is no Interruptible* mutexes, condvars or anything
photon doesn't support the notion and code that relies on
interrupt needs to be rethought (including some part of vibe.d
itself).
3. UDP is stubbed out, because I do not have much of sensible
examples utilizing UDP and felt wrong to port it only to leave it
untested. Anyone using UDP with vibe.d is welcome to give me good
examples preferably with multicast.
4. Timers... Photon has timer related functionality in particular
sleeps but not quite what vibe.d wants so at this point timers
are stubbed out.
5. Fibers are scheduled roughly to the least loaded cores so all
of LocalThis LocalThat are in fact SharedThis and SharedThat,
simplifying the whole thing and making it easier to scale.
6. Processes and process management is stubbed out until I find a
way to implement them in Photon.
7. Files work but may block the thread in some cases, still need
a little bit more support in Photon.
8. Worker threads - there is none at the moment, all is scheduled
on the same pool. Practically speaking this should only affect
CPU intensive tasks, the rest already avoids blocking on syscall
so the primary need for workers is nil.
9. Maybe something else I forgot in the midst of it all.
So closing thoughts - is anyone willing to help me iron out the
inevitable bugs and improve things beyond this proof of concept?
What the community thinks of the idea in general?
