4 ms·
I assume your application is using a dedicated thread for each request? Even then you would be handling more requests in parallel than the number of cores you
by unscaled 8y ago
I assume your application is using a dedicated thread for each request?
Even then you would be handling more requests in parallel than the number of cores you have, but your concurrency would be limited by the cost of context switching and your memory capacity (having to allocate a sizable stack for each thread in most threading implementations).
Queueing is usually required for a stable multi-threaded server, but if you were doing async I/O you wouldn't need it. The extra memory overhead for each extra concurrent request (by means of lightweight coroutine stacks, callbacks or state machines) is not much different from the size it would take on the queue, and there is no preemptive context switching.
In most cases, you'll get the same behavior as having a queue here. Cooperative task-switching happens only on async I/O boundaries, so if you're processing a request that requires some CPU-heavy work, your application would just hog a core until it completes the request and then move to the next one.
- j16sdiz 8y ago> get the same behavior as having a queue here. It is not so easy. The article said it timed out (on the client). When the queue is on client, the client start the timer when the request start.
- ec109685 8y agoSizeable stacks don’t eat into memory unless your thread actually utilizes the full stack allocation. Otherwise, the memory is available for other uses, so you can spin up more threads than you’d think.