Hi Sönke:
I'd like to investigate the possibility of using vibe.d as a high performance server & client.
Our typical usage pattern is this:
- a GET request of about 200~500 Bytes coming in the server.
- some little parsing and redis lookup.
- prepare a JSON/protobuf request, size about 500 Bytes.
- send to multiple upstream servers.
- wait for their response, if one of them is too long, would drop the request (or connection).
- combine the results from upstream servers.
- respond to Browser.
The problem is we might have 5 billion ~ 10 billion request per day. And we need a latency as short as possible.
We are currently using Java, but the memory cost is HUGE for each request. So GC, especially considering the poor implementation of D's GC is a major block.
So my question is, does vibe.d's design support this kind of scenario?
- Does vibe.d use a lot of classes instead of structs? does vibe.d allocate much?
- Does the client support timer and wait/drop?
- how's vibe.d's JSON support in this scenario? would it hurdle the async mode because there are too much CPU work when doing serialization/deserialization?
- how do we utilize multicore in this setup? multiple processes?
- how does vibe.d handle network related errors? (connection break, etc)
As general, what would you suggest if you are to design this system in Vibe.d?