41–50 of 50 posts
Thread-per-connection is just plain dumb. Threads aren't free. Context-switching is a thing. Modern advice is to try not have more threads than cores. Thread-local storage is a very useful, having 1000's of thread may make TLS unfeasible.
Earlier quoted context omitted.
A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…
It's actually a big problem for web servers. If you consider apache for example, that has to do one thread per connection. (yes, apache still doesn't support events for websockets in 2020). Let's say you configure it for 2000 max connections (really not much) so that's 2000 threads, so 20 GB of memory right away because the thread stack is 10 MB on Linux. It's a lot of memory and it's obliterating all caches. You can…
Earlier quoted context omitted.
> The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. Threads haven't exactly stood still in that time either, especially if you include green threads, fibers, coroutines, etc. > If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you. It's relevant regardless, as part of a long-running back and forth…
I don't think there is back and forth anymore. Actual high performance research (e.g. when the cost of a single mutex is more than the whole CPU budget for processing something, like say a packet) has been devoid of threads since they got into the mainstream, so like for almost two decades already. They are still used, because this is what hardware and OS provide to do something on each core, but not for concurrency…
Earlier quoted context omitted.
A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…
A GB of RAM only costs less than $10 if you are buying for your unpretentious gaming rig. A GB of ECC server RAM costs more. An extra GB of RAM in the cloud can even cost you $10/mo if you have to switch to a beefier instance type.
Earlier quoted context omitted.
A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…
It's actually a big problem for web servers. If you consider apache for example, that has to do one thread per connection. (yes, apache still doesn't support events for websockets in 2020). Let's say you configure it for 2000 max connections (really not much) so that's 2000 threads, so 20 GB of memory right away because the thread stack is 10 MB on Linux. It's a lot of memory and it's obliterating all caches. You can…
Earlier quoted context omitted.
I believe one should not confine event-driven only to applications that don't do synchronisation, that's part of the misconception that leads to thinking event-driven has higher performance. This is due to the fact that part of the problem with threads (as you mentioned) is synchronisation, but this is the same problem with event-driven applications. We have a web server experiment that shows comparable performance t…
> I believe one should not confine event-driven only to applications that don't do synchronisation This is just silly. If they do synchronization, they are no longer event driven, they are shared memory multithreaded and are bounded by its performance. In such cases event driven model is not actually used for much, only for I/O notification. So of course comparing shared memory multithreaded application with another…
Earlier quoted context omitted.
I believe one should not confine event-driven only to applications that don't do synchronisation, that's part of the misconception that leads to thinking event-driven has higher performance. This is due to the fact that part of the problem with threads (as you mentioned) is synchronisation, but this is the same problem with event-driven applications. We have a web server experiment that shows comparable performance t…
> I believe one should not confine event-driven only to applications that don't do synchronisation This is just silly. If they do synchronization, they are no longer event driven, they are shared memory multithreaded and are bounded by its performance. In such cases event driven model is not actually used for much, only for I/O notification. So of course comparing shared memory multithreaded application with another…
Earlier quoted context omitted.
A GB of RAM only costs less than $10 if you are buying for your unpretentious gaming rig. A GB of ECC server RAM costs more. An extra GB of RAM in the cloud can even cost you $10/mo if you have to switch to a beefier instance type.
$10/mo is far less than the cost of thinking about the issue at all.
One lesson I've learned is: a) make a library from the get-go, b) make it async/evented from the get-go. This will save you a lot of trouble down the line.
Earlier quoted context omitted.
It's actually a big problem for web servers. If you consider apache for example, that has to do one thread per connection. (yes, apache still doesn't support events for websockets in 2020). Let's say you configure it for 2000 max connections (really not much) so that's 2000 threads, so 20 GB of memory right away because the thread stack is 10 MB on Linux. It's a lot of memory and it's obliterating all caches. You can…
What's wrong with the Apache event worker? https://httpd.apache.org/docs/2.4/mod/event.html
Earlier quoted context omitted.
Sure, if you are devoting the whole computer to a single microbenchmark, threads a terrible idea. This is not necessarily the case when you have many heterogeneous applications running on a machine, though.
I'm a little confused by this- if you have multiple independent apps on a machine, would they not already be in separate OS processes?