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:

  1. a GET request of about 200~500 Bytes coming in the server.
  2. some little parsing and redis lookup.
  3. prepare a JSON/protobuf request, size about 500 Bytes.
  4. send to multiple upstream servers.
  5. wait for their response, if one of them is too long, would drop the request (or connection).
  6. combine the results from upstream servers.
  7. 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?

  1. Does vibe.d use a lot of classes instead of structs? does vibe.d allocate much?
  2. Does the client support timer and wait/drop?
  3. 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?
  4. how do we utilize multicore in this setup? multiple processes?
  5. 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?