Nginx Platform Architecture

Deep understanding of Nginx module open and Architecture Analysis of reading notes.
Nginx after booting, in the UNIX system will be daemon (can be manually shut down nginx.conf daemon off) in the background run, background process contains a master process and multiple worker processes. The master process is primarily used to manage worker processes, including receiving signals from the outside, sending signals to the worker processes, monitoring the health status of the worker process, and automatically restarting the new worker process when the worker process exits (in exceptional cases). The basic network events are handled in the worker process. Multiple worker processes are equivalent, they compete for requests from clients equally, and each process is independent of each other. A request can only be processed in a worker process, and a worker process cannot handle requests from other processes. The number of worker processes can be set, in general we will be set with the machine CPU core number consistent, which causes the Nginx process model and the event processing model is inseparable. Nginx process model, can be represented by the origin.

After Nginx startup, if we want to operate nginx, from the above we can see that master to manage the worker process, so we only need to communicate with the master process is OK. The master process receives signals from the outside world, and then does the different things according to the signals. For example,./nginx-s reload, is to restart Nginx,./nginx-s stop, is to stop nginx operation. How do we do that? We still take reload, we see, when executing the command, we are starting a new nginx process, and the new Nginx process after parsing to the reload parameter, we know that our purpose is to control Nginx to reload the configuration file, it will send a signal to the master process. First, after the master process receives the signal, it reloads the configuration file, starts the new worker process, and sends a signal to all old worker processes that they can retire honorably. After the new worker starts, it begins to receive the new request, and the old worker receives a signal from master, ceases to receive the new request, and exits after processing of all outstanding requests in the current process is complete.

Worker processes are equal, and each process is the same as the opportunity to process requests. When we provide a 80 port HTTP service, a connection request comes in, each process has the possibility to handle this connection, how to do it? First, each worker process is forked from the master process, and in the master process, the socket (LISTENFD) that needs to be listen is first established, and then the multiple worker processes are forked. The LISTENFD of all worker processes becomes readable when a new connection arrives, and to ensure that only one process processes the connection, all worker processes seize Accept_mutex before registering the LISTENFD read event, and the process that grabs the mutex registers the LISTENFD read event. The accept accepts the connection in the Read event. When a worker process begins to read the request, parse the request, process the request, generate the data, and then return it to the client after the connection is accept, this is the complete request. As we can see, a request is handled entirely by the worker process and is handled only in a worker process.

Asynchronous non-blocking feature: Let's go back to the origin and look at the complete process of a request.
First, the request comes in to establish a connection, then receive the data, receive the data, and then send the data. Specific to the bottom of the system, is read and write events, and when the read and write events are not ready, is bound to not operate, if not a non-blocking way to invoke, it will have to block the call (the event is not ready, it can only wait). Blocking calls into the kernel waits, the CPU will let go out to others, for the single-threaded workers, obviously inappropriate, when the network event more time, everyone is waiting, CPU idle No one use, CPU utilization naturally not go, not to talk about high concurrency. Well, you're talking about the number of processes, which is different from the Apache threading model, and be careful not to add unnecessary context switches. Therefore, in Nginx, the most taboo blocking system called. Do not block, it is not blocked. Non-blocking is that the event is not ready to return to Eagain immediately (the requested resource is temporarily unavailable and later access may be available). After a while, check the event until the event is ready, and in the meantime, you can do something else and then look at the event. Although not blocked, but you have to come to check the status of the event from time to moment, you can do more things, but the cost is not small. Therefore, there will be asynchronous non-blocking event handling mechanism, specific to the system call is like Select/poll/epoll/kqueue system call. They provide a mechanism that allows you to monitor multiple events at the same time, call them blocked, but you can set the timeout period, and return if an event is ready in the timeout period. This mechanism solves two of our problems above, take epoll as an example (in the following example, we use Epoll as an example, to represent this kind of function), when the event is not ready, put into the epoll inside, the event is ready, we go to read and write, when read and written return Eagain, We'll add it to the Epoll again. Thus, as soon as the event is ready, we will deal with it and wait in the Epoll only if all the events are not ready. In this way, we can concurrently deal with a large number of concurrent, of course, the concurrent request here, is the request is not processed, the thread only one, so at the same time can handle the request of course only one, only in the request to constantly switch, but also because the asynchronous event is not ready, and the initiative to let out. There is no price to switch here, and you can understand that the loop handles multiple prepared events, which is actually the case. Compared with multithreading, this kind of event processing is a great advantage, do not need to create threads, each request consumes less memory, no context switches, event handling is very lightweight. Any number of concurrent numbers will not result in unnecessary resource wastage (context switching). More concurrency, it just takes up more memory. The author has previously tested the number of connections in 24GMemory, the number of concurrent requests processed has reached 2 million. Today's network server basically use this way, which is the main reason for nginx performance efficiency.

The recommended number of workers is the number of cores of the CPU, which is easy to understand, and more worker numbers will only cause the process to compete for CPU resources. Nginx in order to make better use of multicore features, provides a binding option for CPU affinity, we can bind a process to a certain kernel, so that the process will not be caused by the switchover cache failure.

First, the signal is processed. For Nginx, there are certain signals that represent a particular meaning. The signal interrupts the current operation of the program and continues after the state is changed. If it is a system call, it may cause system calls to fail and need to be re-entered. On the signal processing, we can learn some professional books, not much to say here. For Nginx, if Nginx is waiting for the event (epoll_wait), if the program receives a signal, after processing the signal processing function, Epoll_wait will return an error, and then the program can enter the epoll_wait call again.

Also, take a look at the timer. Since the Epoll_wait function can set a time-out when it is called, Nginx uses this timeout time to implement the timer. Nginx inside the timer event is placed in a maintenance timer in the red black tree, each time before entering the epoll_wait, first from the red black tree to get all the timer event minimum time, in the calculation of the epoll_wait time-out after entering epoll_wait. So, when there is no event, there is no interrupt signal, epoll_wait will time out, that is, the timer event has arrived. At this point, Nginx checks all timeout events, sets their status to timed out, and then handles network events. It can be seen that when we write Nginx code, when we handle the callback function of network events, the first thing we usually do is to judge the timeout and then handle the network event.

We can use a pseudo-code to summarize the Nginx event-handling model:

 while(true) { forTinchRun_tasks:t.handler (); Update_time (& Now); Timeout = eternity; forTinchWait_tasks:/* sorted already */if(T. Time<= Now) {T.timeout_handler (); }Else{timeout = T. Time- Now;        Break } nevents = poll_function (events, timeout); forIinchNevents:task T;if(Events[i].type = = READ)        {T.handler = Read_handler; }Else{/* Events[i].type = = WRITE */T.handler = Write_handler; } run_tasks_add (t);}

Nginx environment construction.

6.6 Uname  -rKernel 版本：2.6.32

cd nginx-x.x.x/./configure  –prefix =/home/renwh/nginx  --without-http_rewrite_module  --without-http_gzip_moduleMakeMake installcd /home/renwh/nginx/bin./nginx(servise iptables stop)

The browser directly accesses the IP address of the machine, you can see the Nginx confirmation interface, then open successfully. Default port: 80

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Nginx Platform Architecture