Differences between multiple multiplexing I/O interfaces epoll select poll in Linux

Let's first introduce nginx: Supports high-concurrency connections. the official test shows 5 W concurrent connections, but 2-4 W concurrent connections can be made in actual production, thanks to nginx's use of the latest epoll (Linux 2.6 kernel) and kqueue (FreeBSD) network I/O models. apache uses the traditional select model. Its stable prefork mode is a multi-process model, which requires frequent distribution of child processes, and consumes more CPU and other server resources than nginx. The reason for the poor efficiency of select and epoll is that select is round-robin and epoll is triggered, so the efficiency is high. In this case, we can understand this sentence. Well, now we can remember this sentence objectively. Let's talk about select: 1. Socket quantity limit: the number of sockets that can be operated in this mode is determined by fd_setsize. The default kernel value is 32*32 = 1024. 2. Operation restriction: The fd_setsize (1024) socket is traversed to complete the scheduling. No matter which socket is active, it is traversed. Poll: 1. The number of sockets is almost unlimited: The FD list corresponding to the socket in this mode is saved by an array, and the size is not limited (4 K by default ). 2. Operation restrictions: Same as select. Besides: epoll: 1. unlimited number of sockets: Same as poll 2. unlimited operation: Based on the reflection mode provided by the kernel, when an active socket exists, the kernel accesses the callback of the socket and does not need to traverse the polling. however, when all sockets are active, all callback will be awakened, which will lead to resource competition. since all sockets need to be processed, traversal is the simplest and most effective implementation method. For example: For im servers, the server and the server are long connections, but the number is not large. Generally, one server is 60 \ 70. For example, the architecture of ice is used, but requests are quite frequent and intensive, at this time, it is not necessarily better to wake up callback through reflection than to traverse with select. For web portal (portal) servers, they are all HTTP short link requests initiated by browser clients. The number of requests is very large, and even better websites may send thousands of requests every minute, at the same time, there are more idle waiting timeout sockets on the server end. At this time, there is no need to traverse all the sockets for processing, because most of the requests waiting for timeout will be better, so epoll will be used. Allows a process to open a large number of socket descriptors. The most intolerable thing about the SELECT statement is that the FD opened by a process has certain limitations, which are set by fd_setsize. The default value is 1024. For im servers that need to support tens of thousands of connections, there are obviously too few. At this time, you can choose to modify this macro and then re-compile the kernel. However, the materials also point out that this will bring about a reduction in network efficiency, second, you can select a multi-process solution (the traditional Apache solution). However, although the cost of creating a process on Linux is relatively small, it cannot be ignored, in addition, data synchronization between processes is far less efficient than inter-thread synchronization, so it is not a perfect solution. However, epoll does not have this limit. The FD limit supported by epoll is the maximum number of files that can be opened. This number is generally greater than 2048. For example, the size of a machine with 1 GB of memory is about 0.1 million. You can check the number of machines with CAT/proc/sys/fs/file-max. Generally, this number has a great relationship with the system memory. Io efficiency does not linearly decrease with the increase in the number of FD Another critical weakness of traditional select/poll is that when you have a large set of sockets, but due to network latency, only some of the sockets at any time are "active, however, each select/poll call will linearly scan all sets, resulting in a linear decline in efficiency. However, epoll does not have this problem. It only operates on "active" sockets-this is because epoll is implemented based on the callback function on each FD in kernel implementation. Then, only the "active" socket will actively call the callback function, and other idle status socket will not. At this point, epoll implements a "pseudo" AIO, this is because the driver is in the OS kernel. In some benchmarks, if all the sockets are basically active-for example, in a high-speed LAN environment, epoll is not more efficient than select/poll. On the contrary, if epoll_ctl is used too much, the efficiency is also slightly lower. However, once idle connections is used to simulate the WAN environment, epoll is far more efficient than select/poll. Use MMAP to accelerate message transmission between the kernel and the user space. This actually involves the specific implementation of epoll. Both select, poll, and epoll require the kernel to notify users of FD messages. It is important to avoid unnecessary memory copies, epoll is implemented through the same memory of the user space MMAP kernel. If you want me to focus on epoll from the 2.5 kernel, you will not forget the manual MMAP step. Kernel fine-tuning This is not an advantage of epoll, but an advantage of the entire Linux platform. Maybe you can doubt the Linux platform, but you cannot avoid the Linux platform giving you the ability to fine-tune the kernel. For example, if the Kernel TCP/IP protocol stack uses a memory pool to manage the sk_buff structure, you can dynamically adjust the memory pool (skb_head_pool) during runtime) by echo XXXX>/proc/sys/NET/CORE/hot_list_length. For example, the listen function's 2nd parameters (TCP completes the length of the packet queue after three handshakes) can also be dynamically adjusted based on the memory size of your platform. Even in a special system with a large number of data packets but the size of each data packet itself is very small, try the latest napi NIC driver architecture.

Reason why the select mode is inefficient
The low efficiency of the select mode is determined by the Select definition and has nothing to do with the operating system implementation. Any kernel must perform a round robin when implementing the SELECT statement to know the situation of these sockets, this will consume CPU. In addition, when you have a large socket set, although only a small part of the socket is "active" at any time, but every time you have to fill in all the sockets in a fd_set, this will also consume some CPU, and when the select returns, you may need to perform "context ing" when processing the business, which also has some performance impact. Therefore, select is relatively inefficient than epoll.
Epoll is applicable to a large number of sockets, but it is not very active.
There is also kqueue. In fact, many servers are developed based on BSD.

 

Http://cppentry.com/bencandy.php? FID = 54 & id = 1129