3 ms·

I don't follow how an "async backend" would help over threads in this case. If you mean using actors everywhere and moving that into client code, you effectivel

I don't follow how an "async backend" would help over threads in this case. If you mean using actors everywhere and moving that into client code, you effectively have a new framework. Likewise, async IO has high throughout but often trades that off for increased latency jitter, since requests can block each other because of the limited thread pool. This is less a problem with threads because of preemption (though they of course compete for shared resources like database time).

merb 5y ago
?! > This is less a problem with threads because of preemption (though they of course compete for shared resources like database time). eh, just because ONE implementation of async is single threaded, does not mean that others aren't. basically you trade of latency because most async implementations do SCHEDULE their tasks/promises in a WORK STEALING fashion (overscheduling and stuff) and another tradeoff is context switching, of course not all task implementations try to reduce that. also if you have blocking operations it might happen that you have two tasks/promises on the same thread, which are lightweight at the beginning and at the end the blocking operation might block the other promise (thus latency for b is reduced) with threads you MIGHT have higher latency in p50, but probably not in p99. of course if you have 16 threads and only 16 requests at any time, the sync engine wins, but most often that is only the case in small applications with few users.