The version before Mix V2.1 has been developed based on multi-process Swoole\Server like the current mainstream Swoole framework. From V2.1, Mix is all based on Swoole's Coroutine/Server development (single-threaded coroutine), so that Server can also be used Fully synchronous programming method, the bottom layer automatically implements asynchronous IO.
Reactor+Manager+Worker multi-process advantages and disadvantages
The process model of Master+Worker is a widely used traditional model, which is used by Nginx and PHP-FPM, but there is one more Manager process in the model of Swoole.
advantage:
- Self-restarting: The biggest advantage of the Reactor+Manager+Worker process architecture is that when any abnormality occurs in the Worker, a Worker process can be restarted by the Manager process of the program itself without the help of a third party (such as supervisor, pm2).
- Multiple CPUs can be utilized: Due to the multi-process model, the Worker process is executed in multiple CPUs, so multiple cores can be utilized.
- Low blocking impact: Because Reactor multithreading is responsible for connection processing, and multiple Worker processes are responsible for executing PHP code, the blocking IO of a single Worker will not affect other requests (coroutine mode, which will affect the process allocated to the process but not completed. request)
shortcoming:
- Coding is complex and not flexible enough: The scope of attribute operation of Swoole\Server class before and after startup is very unfriendly to unfamiliar users, easy to fall into pits, and difficult to understand. When dealing with some global businesses, cross-process processing is required, which brings the problem of concurrent security locks, and it is impossible to start multiple servers at the same time or freely start and stop servers in the code.
- Difficulty in smooth shutdown: Since the program is executed in many worker processes, if there are time-consuming tasks, it is difficult for the multi-process model to finely control each sub-process to execute all the requests of the pipeline, and then exit all processes smoothly and orderly, Swoole\Server Although the asynchronous safe restart feature is provided, most frameworks do not handle onWorkerExit, and it is difficult for users to expand on the basis of the framework.
Advantages and disadvantages of single-threaded coroutines
The single-threaded model is very popular in the field of new software. Redis and Node.js are all single-threaded models, and the advantages and disadvantages are just the opposite of Reactor+Manager+Worker, but Mix provides solutions for these disadvantages.
shortcoming:
- Unable to restart by itself: Mix V2.1 is a common problem in all single-process programs, including programs developed by Golang and Node.js. When a fatal exception occurs, the process will exit. Since it is a single process, it cannot restart by itself. With the help of third parties (such as: supervisor, pm2)
- Unable to take advantage of multiple CPUs: Because it is a single-process model and executed in one CPU, it cannot take advantage of multiple cores like Node.js (there is no such problem with docker deployment).
- Blocking has a large impact: In the single-process model, since the Server and business logic are executed in a single process, when blocking IO is encountered, all request processing will be blocked together, resulting in longer response time, and long-term blocking will also cause the service to fail to receive New request, Swoole Although a large number of blocking IOs in Hook can support coroutines, there are still many extensions that cannot be supported, so this problem is the most prominent.
advantage:
- Simple and flexible coding: Because it is a single-process single-thread model, and the Server is all developed based on Swoole's Coroutine/Server , the programming method is completely synchronous, so the code is very simple and easy to understand. There are also no problems brought about by multiple processes: the problem of object attribute differences across processes, and the problem of concurrent security locks. The Server can also start N at will and stop at will.
- Smooth shutdown is simple: Single-threaded model, only one process needs to be processed to process signals, and only one process needs to be processed to exit. Because of the synchronous programming method, the processing logic of exit is also very simple and easy to understand.
Solutions to shortcomings
From the above analysis, it can be concluded that single thread is simpler and more flexible, but the biggest disadvantage is the blocking problem and the multi-CPU utilization problem. How Mix V2.1 solves these problems:
-
Multi-CPU utilization: Same as Node.js' solution to this problem, the multi-CPU utilization problem is solved by opening multiple processes. Since the same port can only be bound by one program, multiple openings can only be bound to different ports, which is bound to increase. The complexity of the reverse proxy is reduced, but the port multiplexing function is added to the kernel of Linux v3.10 or higher. The built-in Server of Mix only needs to increase the
-rparameters open more port multiplexing in Linux, so as to achieve the same Node.js similar to solve the effect of multi-CPU utilization, see the example . -
Blocking: In the single-process single-thread model, to completely solve the blocking IO problem left by PHP history, it can only be executed by putting the blocking code into one or more other processes, similar to Swoole's Task, except that Mix gets the execution. The result is a synchronous programming method. Mix will encapsulate a synchronous executor, call the synchronous executor in the code and pass in a closure. The closure contains the blocking IO calling code, and the result is obtained synchronously after the call (coroutine method). The closure The code will be passed to the process execution of the synchronous executor by means of unixsocket, and the result will be returned after the execution is completed. The synchronous executor process, like other servers, can add code by itself, and can increase the
-rparameter . Mix centrally executes the blocking code in the synchronous executor process in this way, completely avoiding the impact of blocking. .
After solving these problems, comprehensive consideration of single-threaded coroutines is obviously more in line with Mix's short, compact and easy-to-use positioning. Mix V2.1 is the only framework that fully uses Coroutine/Server as of now .