Am 22.07.2015 um 16:08 schrieb Etienne Cimon:
Personally, I don't like listening on multiple threads, makes things more complicated. I would suggest you send "jobs" to worker tasks instead, using
vibe.core.concurrency, and let the main thread deal with request/response.
Ditto, as long as you have payloads that you can reasonably put into
worker tasks. It simplifies the architecture a lot and can also improve
the response latency in case of CPU intensive tasks.
If you have an architecture where the process doesn't hold permanent
state in-memory (but in a database such as Redis), it's also often a
good idea to start multiple single-threaded processes instead of a
single multi-threaded one because of the garbage collector. The GC is
currently very inefficient in a multi-threaded scenario, so it's very
important to minimize it's use for high-performance multi-threaded
applications (use -version=VibeManualMemoryManagement for vibe.d in that
case).