The synchronization service creates a single thread for each request, and this thread completes the processing of the entire request: receiving messages, processing messages, and returning data; in this case, server resources are open to all push requests, and server resources are competed for use by all push requests , if there are too many push requests, the server resources will be exhausted and downtime, or the competition will be intensified, the resource scheduling will be frequent, and the server resource utilization efficiency will be reduced.
For asynchronous services, two thread queues can be set up, one is dedicated to receiving messages, the other is dedicated to processing messages and returning data, and some guard threads are responsible for task dispatch and timeout monitoring. In this case, regardless of the number of incoming requests, the server always processes requests according to its own capabilities, and server resource consumption is always within a controllable range. One problem with this model is how the sizes of the two thread queues are dynamically adjusted based on the machine load.
For asynchronous service mode:
In this case, although the push request is processed asynchronously in the form of a message queue, each request accesses external resources in a blocking way. If the access speed of external resources is too slow, all threads in the request processing queue may be blocked. In the blocking state, although the CPU usage is very low, it cannot process new messages in the message queue because the threads in the queue are full. At this time, if the maximum number of threads in the thread queue can be adjusted, the CPU utilization can be improved. But another problem is that if the IO processing of all threads ends abruptly after the number of threads is increased and each thread will do a lot of computations then the CPU may be overloaded.
At each point in time when the system is running, the number of threads that are performing IO and the number of threads that are performing calculations are constantly changing, so how can we design a highly adaptive system that can automatically adapt to changes in load according to the current situation of the system? What about the system?
In this regard, the reactive computing model can indeed design a system with strong adaptability to the load, and the system utilization and throughput can be greatly improved, but such a system may still have the risk of excessive partial system load.
Using the reactive computing model, not only the push requests in the system are asynchronous in the form of message queues, but also all IO tasks in the system must follow this method, and the processing of these IO tasks needs to adopt an asynchronous model (such as NIO) . Another thing to consider is how to divide asynchronous IO messages and configure thread queues for them, such as whether to put all IO tasks into a unified queue or set up separate queues for certain types of IO tasks.
Although server resources are allocated by the system, most of them are held and used by threads, such as thread stacks and various locks held by threads.
Reprinted from: http://www.cnblogs.com/zanxiaofeng/p/3758587.html