As discussed in the previous blog, the bottleneck of thread based architecture is that creating a new thread for each event is going to come with a memory footprint which will exhaust all memories or the number of threads the system can support.
The event based architecture is developed to overcome the inherent bottlenecks in the thread based architecture. How does it solved the problem?
There are a few key design decisions. 1) It handles the I/O calling asynchronously or in a non-blocking manner, 2) it create at most one thread for each CPU, 3) the workflow is broken down into individual events, where each of them can be executed independently.
Usually, the requests are first added to the event queue, and there is an execution loop that keep fetching the event from the queue and added to the thread for execution. Since there is only one thread per CPU, it avoided context switch while making sure the CPU can be fully utilized. Hence, the event loop based architecture can achieve much better performance than the traditional thread based architecture.
But the event based architecture comes with a cost: the control flow change brings extra challenges in development. Imaging you have to handle encapsulate the logic into several small piece of call back function which are separated by the I/O operations, such as the DB call.
This programming pattern also make it extremely difficult to test and troubleshooting, as the control flow is not liner while you don’t have a full stack in the call chain.
On the other hand, while this architecture best utilize the CPU bandwidth, the I/O layer such as database can still be a bottleneck, we need multiple other strategies to scale the database layer.
Trackbacks/Pingbacks