Linux Server Network Development Model

Why is Nginx performing much better than Apache?

This is mainly because Nginx uses the latest epoll (Linux 2.6 kernel) and kqueue (FreeBSD) network I/O. Model, while Apache uses the traditional select model. I saw an example on a blog: Suppose you are studying at a university, waiting for a friend to visit, and this friend only knows that you are in Building A, but I don’t know where you live, so you make an appointment. I met at the gate of Building A. If you use the blocking IO model to deal with this problem, then you can only wait for the arrival of friends at the gate of Building A. During this time you can't do anything else, no It's hard to know that the efficiency of this method is low. Now that the times have changed, I started to use the multiplexed IO model to deal with this problem. You tell your friends to come to Building A to find the building aunt, let her tell you. How to get there. The aunt of the building here plays the role of multiplexed IO.

Explain the working mode of the select and epoll models: The select version of the aunt does the following things: For example, the friend of class A comes, the aunt of the select version is stupid, she takes a friend to ask a room to query who is a classmate A, you are waiting for a friend. If every friend who comes to a friend in the building management department has to inquire about the classmates in the whole building, then the efficiency of the processing will inevitably be low. Soon after, there will be quite a lot of people at the bottom of the building. Epoll version of the aunt is more advanced, she wrote down the information of classmate A, such as his room number, then when the friend of class A comes, just tell the friend who classmate A in which room, do not have to bring it yourself Looking for someone in the building. Epoll Aunt can locate classmate A without the power of blowing. At first glance, I understand the difference between epoll and select models.

In the Linux kernel, the FD_SET used by select is limited, that is, there is a parameter in the kernel __FD_SETSIZE defines the number of handles for each FD_SET, in the kernel source /usr/include/linux/posix_types .h #undef __FD_SETSIZE#define __FD_SETSIZE 1024 If you want to detect the readable or writable state of 1025 handles at the same time, select is not possible. Implementing select in the kernel uses the polling method, that is, each check will traverse all the handles in the FD_SET. Obviously, the more the execution time of the select function and the number of handles detected by the FD, the more time consuming.

epoll is a way of multiplexing IO (I/O Multiplexing), only for linux2.6 and above. The epoll model supports the maximum FD limit, which is the maximum number of open files. This number is generally much larger than 2048. For example, on a 1GB memory machine is about 100,000. For details, please see: cat /proc/sys/Fs/file-max , this number has a lot to do with system memory. Another fatal weakness of the traditional select/poll is that when you have a large socket collection, but due to network latency, only part of the socket at any time is "active", but select/poll will be linear each time it is called. Scanning all the collections results in a linear decrease in efficiency. But epoll doesn't have this problem, it only operates on the "active" sockets -- this is because in the kernel implementation epoll is implemented according to the callback function on each fd. Then, only the "active" socket will actively call the callback function, and other idle state sockets will not. At this point, epoll implements a "pseudo" AIO, because this time the driving force is in os Kernel. In some benchmarks, if all sockets are basically active -- such as a high-speed LAN environment, epoll is no more efficient than select/poll. On the contrary, if you use epoll_ctl too much, the efficiency is slightly lower. . But once you use idle connections to simulate a WAN environment, epoll is much more efficient than select/poll.

Epoll has two working modes: Edge Triggered (ET), Level Triggered (LT) LT (level triggered) is the default mode of operation, and supports both block and no-block sockets. The kernel tells you if a file descriptor is ready, and then you can perform IO operations on this ready fd. If you don't do anything, the kernel will continue to notify you, so this mode is less likely to be programmed. The traditional select/poll is representative of this model. ET (edge-triggered) is a high-speed mode of operation that only supports no-block sockets. In this mode, the kernel tells you via epoll when the descriptor has never been ready to become ready. Then it assumes that you know that the file descriptor is ready and will not send more ready notifications for that file descriptor until you do something that causes the file descriptor to be no longer ready (for example, you An EWOULDBLOCK error is caused when sending, receiving, or receiving a request, or sending and receiving less than a certain amount of data.