Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to analyze the Linux server network development model, the quality of the article content is high, so Xiaobian shares it with you as a reference, I hope you have a certain understanding of related knowledge after reading this article.

Why is Nginx so much better than Apache?

This is mainly because Nginx uses the best epoll(Linux 2.6 kernel) and kqueue(FreeBSD) network I/O models, while Apache uses the traditional select model.

Explain how select and epoll models work:

Select version aunt is doing the following things: For example, classmate A's friend came,select version aunt is stupid, she took friends to check room by room who is classmate A, your friend came. If every time a friend comes to the building, the aunt has to inquire about the whole building, then the efficiency of processing will inevitably be low, and soon there will be a lot of people at the bottom of the building.

Epoll version aunt is more advanced, she wrote down the information of classmate A, such as his room number, so when classmate A's friend arrives, just need to tell the friend classmate A in which room, do not have to personally bring people to find people in the building. Aunt epoll can locate classmate a without any effort. The difference between epoll and select models is obvious.

In the Linux kernel, FD_SET used by select is limited, that is, there is a parameter__FD_SETSIZE in the kernel that defines the number of handles for each FD_SET. In the kernel source code,/usr/include/linux/posix_types. h

#undef __FD_SETSIZE#define __FD_SETSIZE 1024

Select is impossible if you want to detect the readable or writable state of 1025 handles simultaneously. Select is implemented in the kernel using a polling method, i.e., each check iterates through all the handles in FD_SET. Obviously, the more time the select function takes to execute and the number of handles FD checks, the more time it takes.

epoll is a way of multiplexing IO(I/O Multiplexing), only for linux 2.6 and above kernels. The FD limit supported by epoll model is *** the number of files that can be opened. This number is generally much larger than 2048. For example, on a machine with 1GB memory, it is about 100,000. For details, please see cat /proc/sys/fs/file-max. This number has a great relationship with system memory.

Another Achilles heel of traditional select/poll is when you have a large set of sockets, but because of network latency, only some of the sockets are "active" at any one time, but select/poll scans the entire set linearly with each call, resulting in a linear decline in efficiency. But epoll doesn't have this problem, it only operates on "active" sockets--that's 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, other idle state sockets will not, at this point, epoll implements a "pseudo"AIO, because the driving force is in the os kernel. In some benchmarks, epoll is no more efficient than select/poll if all sockets are basically active--say, in a high-speed LAN environment, whereas epoll_ctl is slightly less efficient if used too much. But once idle connections are used to simulate a WAN environment,epoll is far more efficient than select/poll.

ePoll has two modes of operation:Edge Triggered (ET) and Level Triggered (LT).

LT(level triggered) is the default mode of operation, and supports both block and no-block sockets. In this way, the kernel tells you whether a file descriptor is ready, and then IO operations can be performed on the ready fd. If you don't do anything, the kernel will continue to notify you, so programming in this mode is less likely to make mistakes. 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 goes from not ready to ready. It then assumes that you know that the file descriptor is ready and will not send any more ready notifications for that file descriptor until you do something that causes that file descriptor to no longer be ready (e.g., you send, receive, or receive requests, or send or receive less than a certain amount of data, causing an EWOULDBLOCK error).

About how to analyze the Linux server network development model to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.