: This article mainly introduces the Nginx-event processing mechanism and process model. For more information about PHP tutorials, see. Nginx event handling mechanism:
For a basic web server, there are usually three types of events: Network events, signals, and timers.
First, let's take a look at the basic process of a request: establish a connection-receive data-send data.
Next, let's look at the underlying operations of the system: the above process (establishing a connection-receiving data-sending data) is a read/write event at the underlying level of the system.
1) If you use the blocking call method, when the read/write events are not ready, the read/write events will inevitably not be able to be performed, so long wait until the events are ready before the read/write events can be performed. The request will be delayed. Blocking calls will enter the kernel waiting, and the cpu will be used by others. it is obviously not suitable for single-threaded worker. when there are more network events, everyone will be waiting, when the cpu is idle, no one will use it. the cpu utilization will naturally fail, let alone high concurrency.
2) since the call cannot be blocked, the non-blocking method is adopted. If it is not blocked, the event immediately returns EAGAIN, telling you that the event is not ready yet. What are you panic about? come back later. Okay. after a while, check the event again until the event is ready. during this period, you can do other things first, and then check whether the event is ready. Although it is not blocked, you have to check the event status from time to time. you can do more, but the overhead is not small.
Conclusion: non-blocking checks the status of events to determine whether to perform read/write operations. This results in high overhead.
3) so there is an asynchronous non-blocking event processing mechanism. Specifically, system calls are system calls like select/poll/epoll/kqueue. They provide a mechanism for you to monitor multiple events at the same time, and call them is blocked, but you can set the timeout time. if an event is ready within the timeout time,. This mechanism solves the two problems above.
Taking epoll as an example: when the event is not ready, put it in the epoll (queue. If an event is ready, process it. if the event returns EAGAIN, add it to epoll. Therefore, as long as the event is ready, we will handle it. only when there is no preparation at all time will we wait in epoll. In this way, we can process a large number of concurrent requests concurrently. of course, the concurrent requests here refer to the unfinished requests with only one thread, therefore, there is only one request that can be processed at the same time, but the requests are constantly switched. The switchover is also because the asynchronous events are not ready and the requests are automatically made. There is no price for switching here. you can understand it as loop processing of multiple prepared events. In fact, this is the case.
4) comparison with multithreading:
Compared with multithreading, this event processing method has great advantages. no threads need to be created, and each request occupies a small amount of memory. there is no context switch, and event processing is very lightweight. A large number of concurrent operations will not cause unnecessary resource waste (context switching ).
Summary: through asynchronous non-blocking event processing mechanism, Nginx processes multiple prepared events cyclically to achieve high concurrency and lightweight.
Nginx features:
1. cross-platform: Nginx can be compiled and run in most Unix like OS versions, and also has a Windows transplant version.
2. the configuration is very simple and easy to use. The configuration style is the same as that of program development.
3. non-blocking and high-concurrency connections: During data replication, the first phase of disk I/O is non-blocking. The official test supports 50 thousand concurrent connections and runs to 2 ~ in the actual production environment ~ 30 thousand concurrent connections (thanks to Nginx's use of the latest epoll model)
4. event-driven: the communication mechanism uses the epoll model to support larger concurrent connections.
5. no persistent connection is required between the nginx proxy and the backend web server;
6. receiving user requests is asynchronous, that is, all user requests are received first, and then sent at one time to the backend web server, which greatly reduces the pressure on the backend web server.
7. when sending a response message, it receives data from the backend web server and sends it to the client.
8. low network dependency. NGINX has a very low dependence on the network. theoretically, as long as it can be pinged, load balancing can be implemented, and intranet and internet traffic can be effectively differentiated.
9. supports server detection. NGINX can check whether the server is faulty based on the status code and timeout information returned by the application server processing page, and timely return the error request and resubmit it to other nodes.
Master/worker structure: a master process that generates one or more worker processes
Small memory consumption: the memory consumption for processing large concurrent requests is very small. With 30 thousand concurrent connections, enabling 10 Nginx processes consumes 150 MB of memory (15 MB * 10 = MB) at a low cost: Nginx is an open-source software and can be used for free. The purchase of F5 BIG-IP, NetScaler and other hardware server load balancer switches requires over 100,000 to several hundred thousand RMB
Built-in health check: If a Web server on the Nginx Proxy is down, front-end access is not affected.
Bandwidth saving: GZIP compression is supported. you can add the Header cached locally by the browser.
High stability: used for reverse proxy, with minimal probability of downtime
Nginx works in a multi-process manner. of course, nginx also supports multithreading, but our mainstream approach is also a multi-process approach, which is also the default approach of nginx. Nginx adopts the multi-process method, which has many advantages.
(1) after nginx is started, there will be one master process and multiple worker processes. The master process is mainly used to manage worker processes, including receiving external signals, sending signals to worker processes, and monitoring the running status of worker processes, when the worker process exits (abnormal), it automatically restarts the new worker process. The basic network events are handled in the worker process. Multiple worker processes are peer-to-peer. they compete for requests from clients, and each process is independent of each other. One request can only be processed in one worker process. one worker process cannot process requests from other processes. The number of worker processes can be set. Generally, the number of cpu cores is the same as that of the machine. The reason is that the nginx Process Model and event processing model are inseparable.
(2) How does the Master process the received signal (./nginx-s reload )?
First, the master process will re-load the configuration file after receiving the signal, then start the new process, and send a signal to all old processes, telling them that they can retire with honor. After a new process is started, it starts to receive new requests. after receiving a signal from the master, the old process no longer receives new requests, and exit after all unprocessed requests in the current process are processed.
(3) How does the worker process requests?
As we have mentioned above, worker processes are equal, and each process has the same opportunity to process requests. When we provide an http service with Port 80 and a connection request comes over, every process may process this connection. how can this problem be solved? First, each worker process comes from the master process fork. in the master process, first establish the socket that requires listen, and then fork multiple worker processes, in this way, each worker process can go to the accept socket (of course not the same socket, but the socket of each process will monitor the same IP address and port, this is allowed in the network protocol ). In general, when a connection comes in, all the processes on this socket will receive a notification, and only one process can access this connection, while others will fail, this is a group shock phenomenon. Of course, nginx won't turn a blind eye, so nginx provides an accept_mutex. from the name, we can see that this is a shared lock applied to the accept. With this lock, there will be only one process connected to accpet at the same time, so there will be no group issues. Accept_mutex is a controllable option, which can be turned off explicitly. it is enabled by default. After a worker process connects to accept, it starts to read the request, parse the request, process the request, generate the data, and then return it to the client. the connection is closed, such a complete request is like this. We can see that a request is completely handled by the worker process and only processed in one worker process.
(4) What are the advantages of nginx adopting this process model?
The use of independent processes can ensure that they do not affect each other. after a process exits, other processes are still working and the service will not be interrupted. The master process will soon restart the new worker process. Of course, the abnormal exit of the worker process must be due to a bug in the program. The abnormal exit will cause all requests on the current worker to fail, but will not affect all requests, thus reducing the risk. Of course, there are many benefits that you can learn from.
(5) nginx uses multiple worker methods to process requests. each worker has only one master thread, so the number of concurrent jobs that can be processed is limited, how many workers can process and how many concurrency can be processed? why is high concurrency? That is, nginx uses asynchronous and non-blocking methods to process requests. that is to say, nginx can process thousands of requests simultaneously.
Each request on the IIS server excludes one worker thread. when the number of concurrent threads reaches several thousand, several thousand threads are processing the request at the same time. This is a great challenge for the operating system. the memory occupied by threads is very large, and the cpu overhead caused by thread context switching is very high, so the natural performance will not go up, these overhead are completely meaningless. As we have said before, it is recommended to set the number of workers to the number of cpu cores. it is easy to understand here that more workers will only lead to processes competing for cpu resources, this leads to unnecessary context switching. In addition, to better utilize the multi-core features, nginx provides cpu affinity binding options. we can bind a process to a certain core, in this way, the cache will not become invalid due to process switching.
Server load balancer
The server load balancer technology provides a cheap, effective, and transparent method based on the existing network structure, to expand the bandwidth of network devices and servers, increase throughput, enhance network data processing capabilities, and improve network flexibility and availability. It has two meanings: first, a large amount of concurrent access or data traffic is distributed to multiple node devices for separate processing, reducing the user's waiting for response time; second, the operation of a single heavy load is distributed to multiple node devices for parallel processing. after each node device finishes processing, the results are summarized and returned to the user, which greatly improves the system processing capability.
The above introduces the Nginx-event processing mechanism and process model, including some content, and hope to be helpful to friends who are interested in PHP tutorials.
