4-nginx Processing Request Process

1. Working mechanism of the worker process

Now we understand how the worker process handles requests when we are doing something inside the nginx when we operate nginx.

As we mentioned earlier, the worker processes are equal, and each process has the same opportunity to handle the request.

When we provide 80-port HTTP service, a connection request comes in, each process is likely to handle this connection, how to do it.

First, each worker process is fork from the master process, and in the master process, the listen socket (LISTENFD) is built first, meaning that the master process listens for requests from the client, And then fork out multiple worker processes. And the listenfd of all worker processes becomes readable when new connections arrive, and all worker processes Rob Accept_mutex before registering LISTENFD read events to ensure that only one process handles the connection. The process of processing a request by a worker process is probably shown in the following figure:

Look at the map order is first look at the green, and then look at the blue, and finally look red.
The green section represents the request sent by the client, and the blue section represents the worker process for Master Process Management (fork), and the Red section indicates that the worker process robs the Accept_mutex, the gray section indicates the registration event, and then Accpet accepts the connection and processes it.

For nginx preemption mechanisms, when the master process listen to requests sent from the client, all idle worker processes Rob Accept_mutex and grab Accept_ The worker process of a mutex (mutex) registers LISTENFD read events, and then calls accept to receive and process the client's request in a read event.

NOTE: * * all * * * In the idle worker process before accept receive client request, will be the client's Accept_mutex lock Try_lock attempt to lock, it is necessary to emphasize that the process is competitive.

The other thing to understand is why this is try_lock (try lock), not lock (lock).

Assuming lock, all other worker processes that lock and lock the client's Accept_mutex lock are blocked except for a successful worker process that Accept_mutex the client's request. Unless the client-requested Accept_mutex lock-Successful worker process calls unlock for unlock (which wakes up all other worker processes in this accept_mutex while unlocking), Otherwise, other worker processes will always be blocked in this idle state, which is bound to cause waste of resources.

If it is try_lock, then the other worker processes will immediately return to client attempts to lock down, to handle other client requests, so no other worker process will be blocked here, and there will be no waste of resources.

When a worker process to the client Accept_mutex lock success, accept this connection and register read events, began to read the request, parse the request, processing requests, produce data, and then return to the client, finally disconnected, a complete request is this. 2. Nginx Processing Request Process

Nginx uses a multiple process model to provide services, a master process and multiple worker processes, and the master process is responsible for managing the nginx itself and other worker processes.

All the actual business processing logic is in the worker process. The worker process has a function that performs an infinite loop, processes incoming requests from the client, and processes them until the entire Nginx service is stopped.

In the

worker process, the ngx_worker_process_cycle () function is the processing function of this infinite loop. In this function, a simple processing process for a request is as follows: The mechanism provided by the operating system (such as Epoll, kqueue, etc.) produces related events. Receiving and handling these events, and accepting the data, results in higher-level request objects. Handle the header and body of the request. Generates a response, processes the response data, and sends it back to the client. Complete the request processing. Re-initialize the timer and other events and disconnect the connection.