Using Epoll to develop High-performance application servers on Linux

Overview

Epoll is Linux provides a multiplexing technology, similar to each platform to support the Select, but only epoll in the implementation of the kernel to do more optimization, can support more than select File descriptor, of course, also support the socket of the network file descriptor. Linux on the large concurrent access server, the current implementation of the way is certainly through the epoll implementation.

Epoll and Threads

There are many developers using Epoll, will open a number of threads for data communication, such as a thread dedicated accept (I personally earlier in the FreeBSD with Kqueue, because of the internal mechanism is not basic understanding also do so), a thread to send and receive, or received and sent Send each with its own separate thread.

In general, it is not necessary to accept independent threads, accept for the kernel to read a little bit of data from the unfinished SYN queue of the kernel. See Accept section specifically:

Introduction of TCP Three-time handshake process and corresponding Berkeley Socket APIs

It is not necessary to send and receive independently into two threads, because most of the application servers, typically, start a thread to send and receive data, and the maximum data delivery bottleneck is the network card, not the CPU; like the online game access server configuration a KM network card, few games will apply for 1G of bandwidth, How much data input and output the machine has to have. So our communication thread for the Epoll server is enough.

The basic principle of epoll

In order for some friends to be more accustomed to reading, I still say the basic principle of epoll.

Epoll external performance is the same as select. He provides events such as read, write, and error.

The approximate process is as follows:

1. Apply the events of interest to the kernel;

2. The kernel under certain conditions, notify the application of the event;

3. After the application receives the event, the corresponding logical processing is done according to the event type.

The principle part, I repeat, is not easy to understand, including the level trigger and the edge trigger, the event utilization of the Write event (this can be combined with reference 1 of Kqueue's write event, principle consistent) and modify the event details.

Horizontal Trigger

The Read event, the socket recv buff has data, will be notified to the application until buff is empty.

The write event, the socket send buff from full state to the data that can be sent, will always notify the application until buff full.

Edge Trigger

Read event, Socket recv buff have data, only notify application once, regardless of whether the application has called the Read API, the next is not notified.

Write event, the socket send buff from full state to can send data, only one notification.

The above explanation does not know whether you can understand, and can only say so. Have a question to do the experiment. In addition, these details of things, a few years after the fixed, these years to do projects, is directly used, but also rarely in the details involved, is based on understanding and memory written words, if wrong please correct.

Use of Write events

That's a bad description. A general description, a detailed look at reference 1. Roughly like this:

1. The logical layer writes the data to the application layer sends the buff, registers the write event to the Epoll;

2. At this time Epoll will notify the application of a write event;

3. In the Write event response function, the buff reads data from the application layer and sends it using the socket send API.

Because I am in many actual projects, see people do not use Epoll write event to send data, specifically to say. Most of the projects are directly polling the application's sending queues, as did my early projects.