[Reading Notes] 1_A preliminary exploration of nginx architecture_2_How does the event processing mechanism achieve high concurrency?

Original text: http://tengine.taobao.org/book/chapter_02.html

nginx uses a multi-worker method to process requests. There is only one main thread in each worker, so the number of concurrency it can handle is very limited. How many workers can handle as many concurrencies as possible, so how can we achieve high concurrency?

nginx uses an asynchronous non-blocking method to process requests, and this asynchronous non-blocking event processing mechanism, specifically system calls, are system calls like select/poll/epoll/kqueue. They provide a mechanism that allows you to monitor multiple events at the same time. Calling them is blocking, but you can set a timeout. Within the timeout, if an event is ready, it will return.

Take epoll as an example (in the following examples, we often use epoll as an example to represent this type of function)

1. When the event is not ready, put it in epoll
2. When the event is ready, we Go to read and write
3. When the read and write returns EAGAIN, we add it to epoll again.

In this way, as long as an event is ready, we will process it. Only when all events are not ready, we will wait in epoll. In this way, we can handle a large amount of concurrency concurrently.

Of course, the concurrent requests here refer to unprocessed requests. There is only one thread, so of course there is only one request that can be processed at the same time. It is just a constant switch between requests. The switch is also because the asynchronous event is not ready. , and voluntarily gave up. There is no cost to switching here. You can understand it as processing multiple prepared events in a loop, which is actually the case. Compared with multi-threading, this event processing method has great advantages. There is no need to create threads, each request occupies very little memory, there is no context switching, and event processing is very lightweight. No matter how many concurrencies there are, it will not lead to unnecessary waste of resources (context switching).

More concurrency numbers will only occupy more memory.

The number of worker processes mentioned before can be set. Generally, we will set it to be consistent with the number of CPU cores of the machine. The reason for this is inseparable from the process model and event processing model of nginx.

It is recommended to set the number of workers to the number of CPU cores. It is easy to understand here. More workers will only cause processes to compete for CPU resources, resulting in unnecessary context switching. Moreover, in order to better utilize the multi-core features, nginx provides a cpu affinity binding option. We can bind a certain process to a certain core, so that the cache will not fail due to process switching. Small optimizations like this are very common in nginx, and it also illustrates the painstaking efforts of the nginx author. For example, when nginx compares 4-byte strings, it will convert the 4 characters into an int type and then compare them to reduce the number of CPU instructions and so on.

The above introduces [Reading Notes] 1_Initial exploration of nginx architecture_2_How does the event processing mechanism achieve high concurrency, including aspects of the content. I hope it will be helpful to friends who are interested in PHP tutorials.