Nginx works in a multi-process way.

Nginx works in a multi-process way .

Nginx works in a multi-process way.
Nginx after booting, there will be a master process and multiple worker processes.

The master process is primarily used to manage worker processes:
Contains:
1. Receive signals from outside and send signals to each worker process.
2. Monitor the running state of the worker process and automatically restart the new worker process when the worker process exits (in exceptional cases).
The basic network events are handled in the worker process. Worker processes are peers, 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 is typically set to coincide with the number of machine CPU cores. When we provide a 80 port HTTP service, a connection request comes in and each process is likely to handle the connection.


The process is as follows:
Master (the master process first establishes the socket that needs to be listen)--------fork to generate the subprocess workers, inherit the socket (workers child processes inherit all the properties of the parent process master, and, of course, include
The establishment of a good socket, of course, is not the same socket, but each process of the socket will be monitored in the same IP address and port, which is allowed in the network protocol)------When a connection entered, generating a surprise group phenomenon.
In general, when a connection comes in, all the processes that are on the socket are notified, and only one process can accept the connection, and the others accept the failure.

Surprise group phenomenon:When an FD event is triggered, all threads/processes waiting for this FD are awakened. Although all are awakened, only one will respond. The most common example is the accept operation of the socket, when more than one user process/thread listening on the same port, because it is only possible to accept once, so there will be a surprise group phenomenon,

The treatment of surprise group phenomenon by Nginx:Nginx provides a accept_mutex this thing, which is a shared lock added on the accept. With this lock, at the same moment, there will only be one process in the Accpet connection, so
There will be no surprise problem. Accept_mutex is a controllable option that we can display to turn off, which is turned on by default.


worker process work:
When a worker process begins to read the request, parse the request, process the request, generate the data, and then return to the client after the connection is accept, a complete request is finally disconnected. A request is handled entirely by the worker process and is handled only in a worker process.
Summary:
1) A complete request read request, parse the request, process the request, generate the data, then return to the client, and finally disconnect.
2) A complete request is handled entirely by a worker process.
Benefits: 1) Save on lock overhead. Each worker process is a stand-alone process that does not share resources and does not require locks. It also has a lot of convenience when it comes to programming and problem checking.
2) independent process, reduce risk. The use of independent processes can make no difference between each other, after a process exits, other processes are still working, the service will not be interrupted, and the master process will soon restart the new worker process. Of course, the worker process unexpectedly exits, must be the program has a bug, the exception exits, will cause all requests on the current worker to fail, but does not affect all requests, so reduces the risk.

The event handling mechanism of Nginx
for a basic Web server, there are typically three types of events: Network events, signals, timers. Nginx uses an asynchronous, non-blocking event-handling mechanism that processes multiple prepared events through a process, enabling

High concurrency and lightweight.
    Epoll for example: When the event is not ready, put it in Epoll. If the event is ready, then go ahead and if the event returns Eagain, continue to put it into epoll. Thus, as soon as the event is ready, we will deal with her and wait in the Epoll only when all the time is 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.

Problem 1:nginx The worker process is used to process requests, and a worker process has only one main thread, so how many worker child processes can handle the concurrency, and the number of concurrency that can be handled is limited. In a nutshell, how does nginx achieve high concurrency?     Answer 1: Adopt an asynchronous, non-blocking event-handling mechanism. The ability to concurrently process a large number of unhandled requests is a process that loops through asynchronous, non-blocking methods to handle multiple prepared events. Take Epoll as an example, the prepared event will be put into the epoll, as long as the event is ready, it will be processed.                   

question 2: What is asynchronous non-blocking mode           Answer 2:http://www.ibm.com/developerworks/cn/linux/l-async/

The difference between the problem 3:nginx and Apache for high concurrency processing.
Answer 3: For Apache, each request will have a single worker thread, and when the number of concurrent numbers reaches thousands of, then thousands of of the threads are processing the request. For the operating system, the memory is very large, the thread context switch brings a lot of CPU overhead, performance is difficult to go up, and these costs are completely meaningless.

For Nginx, a process with only one main thread, through asynchronous non-blocking event processing mechanism, to achieve the loop processing of a number of prepared events, so as to achieve lightweight and high concurrency.

Question 4: Why is the number of worker referrals CPU?
Answer 4: Because more worker numbers will only cause the process to compete with each other for CPU resources, resulting in unnecessary context switching
Discussion on the Nginx architecture of reference http://tengine.taobao.org/book/chapter_2.html#connection
=======================================================================================================

Nginx comparison Apache: Event-driven for IO-intensive services, multi-process or thread-appropriate for CPU-intensive services

1) Nginx is mostly used as a reverse proxy, not a Web server. Its network mode is event driven (SELECT, poll, Epoll).
2) The nature of the event-driven is the IO event, where the application quickly switches between multiple IO handles to implement so-called asynchronous IO.
3) Event-driven server, the most suitable to do is this IO-intensive work, such as reverse proxy, it between the client and the Web server a data transfer function, purely IO operation, itself does not involve complex computing.
4) Reverse proxy with event-driven to do, obviously better, a working process can run, no process, thread management overhead, CPU, memory consumption is small.
5) Of course, Nginx can also be a multi-process + event-driven mode, a few processes run libevent, do not need Apache as much as hundreds of of the process number.
6) Nginx processing static file effect is also very good, that is because the static file itself is disk IO operation, the same process. As for the number of concurrent connections, this is meaningless. I write a network program can handle tens of thousands of 7) concurrency, but if the majority of clients blocked there, there is little value.

Look at Apache or resin applications such as server, they are called application servers, because they really want to run specific business applications, such as scientific computing, graphic images, database reading and writing. They are probably CPU-intensive services, and event-driven is not appropriate.

1) For example, a calculation takes 2 seconds, then these 2 seconds are completely blocked and no event is useless. Think about MySQL. If you change to an event driver, a large join or sort will block all clients.
2) At this time the multi-process or thread will show the advantages, each process of each of the things, non-blocking and interference. Of course, the modern CPUs are getting faster, and the time for a single computational blockage can be small, but as long as there is blocking, event programming has no advantage. So the process, threading technology, does not disappear, but with the event mechanism to complement, long-term existence.
In summary, event-driven is suitable for IO-intensive services, multi-process or thread-appropriate for CPU-intensive services, each with their own advantages, and there is no inclination to replace who.

Nginx works in a multi-process way.