Advantages of Epoll:
1. Support a process to open a large number of socket descriptors (FD)
Select the most unbearable is a process opened by the FD is a certain limit, set by Fd_setsize, the default value is 2048. It is obviously too small for the number of connected IM servers that need to be supported. At this time you can choose to modify the macro and then recompile the kernel, but the data also pointed out that this will bring down the network efficiency, the second is the choice of multi-process solution (traditional Apache scheme), but although the cost of the creation process of Linux is relatively small, but still can not be ignored, Coupled with inter-process data synchronization is far less efficient than synchronization between threads, so it is not a perfect solution. However, Epoll does not have this restriction, it supports the FD limit is the maximum number of open files, this number is generally far greater than 2048, for example, in 1GB memory of the machine about 100,000, the specific number can be cat/proc/sys/fs/file-max to see, In general, this number is very much related to system memory.
2.IO efficiency does not decrease linearly with increasing number of FD
Another Achilles heel of traditional select/poll is when you have a large socket set, but because of network latency, only some of the sockets are "active" at any one time, but select/poll each call will scan the entire collection linearly. resulting in a linear decrease in efficiency. However, Epoll does not have this problem, it only operates on "active" sockets---This is because Epoll is implemented in the kernel implementation based on the callback function above each FD. Then, only the "active" socket will be active to call the callback function, the other idle state socket will not, at this point, Epoll implemented a "pseudo" AIO, because this time the driving force in the OS kernel. In some benchmark, if all sockets are basically active---such as a high-speed LAN environment, Epoll is no more efficient than select/poll, and conversely, if you use epoll_ctl too much, there is a slight decrease in efficiency. But once you use the idle connections to simulate a WAN environment, epoll is far more efficient than select/poll.
3. Use Mmap to accelerate message delivery between the kernel and user space.
This actually involves the concrete implementation of the Epoll. Both Select,poll and epoll need the kernel to inform the user of the FD message, how to avoid unnecessary memory copy is very important, at this point, epoll through the kernel in the user space mmap the same piece of memory implementation. And if you want me to follow epoll from the 2.5 kernel, you will never forget to mmap this step manually.
4. Kernel Trimming
This is not really a epoll advantage, but the advantages of the entire Linux platform. Maybe you can doubt the Linux platform, but you can't avoid the Linux platform that gives you the ability to fine-tune the kernel. For example, the kernel TCP/IP stack uses a memory pool to manage the sk_buff structure, so the size of this memory pool (Skb_head_pool) can be dynamically adjusted at runtime---via Echo xxxx>/proc/sys/net/core/hot_ List_length completed. Another example is the 2nd parameter of the Listen function (TCP completes the packet queue length of 3 handshake), or it can be adjusted dynamically depending on the size of your platform memory. Even try the latest NAPI NIC driver architecture on a special system that has a large number of packet polygons but also has a small size for each packet itself.
Multiplexing is a truly practical server program, and a non-multiplexed network program can only be used as a learning or accompanying role.
The advantage over Select,epoll is that it listens for more FD numbers and handles events more efficiently (no need to traverse all FD).
The main API:
1. int epoll_create (int size);
Creates a handle to a epoll that represents the number of listeners.
2. int epoll_ctl (int epfd, int op, int fd, struct epoll_event *event);
The event registration function for Epoll.
EPFD: Epoll-specific file descriptor generated by epoll_create;
OP: Registered event, possible value: Epoll_ctl_add, Epoll_ctl_mod, Epoll_ctl_del
FD:FD: Listener's file descriptor
Event: Pointer to Epoll_event
struct Epoll_event {
__uint32_t events;
epoll_data_t data;
};
Events can be a collection of several macros:
Epollin: Indicates that the corresponding file descriptor can be read (including a graceful shutdown of the peer socket);
Epollout: Indicates that the corresponding file descriptor can be written;
Epollpri: Indicates that the corresponding file descriptor has an urgent data readable (this should indicate the arrival of out-of-band data);
Epollerr: Indicates an error occurred in the corresponding file descriptor;
Epollhup: Indicates that the corresponding file descriptor is hung up;
Epollet: Set Epoll to edge triggered mode.
Epolloneshot: Listen to only one event
3. int epoll_wait (int epfd, struct epoll_event * events, int maxevents, int timeout);
The Epoll event wait function.
EPFD: Epoll-specific file descriptor generated by epoll_create;
Events: An array for callback events;
Maxevents: The length of the event array;
Timeout: The time-out value waiting for the I/O event to occur;
Other:
The LT (level triggered) is the default mode of operation and supports both block and No-block sockets. In this practice, the kernel tells you if a file descriptor is ready, and then you can do an IO operation on the Ready FD. If you do not do anything, the kernel will continue to inform you, the traditional select/poll is the representative of this model.
ET (edge-triggered) is a high-speed mode of operation and supports only no-block sockets. In this mode, when the descriptor is never ready to be ready, the kernel tells you through Epoll. It then assumes that you know that the file descriptor is ready and no more ready notifications are sent for that file descriptor until you do something that causes the file descriptor to no longer be ready.
I/O multiplexing---epoll notes
