epoll LT/ET deep dive

From: http://dongfuye.iteye.com/blog/2282573




epoll LT/ET There are two models for in-depth analysis

of EPOLL events:

Level Triggered (LT) Level Triggered . The socket
receive buffer is not empty, there is data to read and the event is always read Trigger . If the socket
send buffer is not full, you can continue to write data. The write event is always triggered. In
line with the habits of thinking, the event returned by epoll_wait is the state of the socket

Edge Triggered (ET) Edge Triggered
. When the state of the receive buffer of the socket changes, the read event is triggered, that is, it is empty. The read event is triggered when the receive buffer of the socket has just received data.
The write event is triggered when the state of the send buffer of the socket changes, that is, the read event is triggered when the full buffer just empties the space. The event is triggered
only when the state changes

ET or LT?

LT The processing process:
. Accept a connection, add it to epoll and listen to the EPOLLIN event
. When the EPOLLIN event arrives, read the data in fd and process it
. When the data needs to be written, write the data to fd; if the data is large, If the data cannot be written out at one time, then listen for the EPOLLOUT event in epoll
. When the EPOLLOUT event arrives, continue to write the data to fd; if the data is written out, close

the processing of the EPOLLOUT event ET in epoll:
. accept one by one Connect, add to epoll to listen for EPOLLIN|EPOLLOUT events
. When the EPOLLIN event arrives, read the data in fd and process it. Read needs to keep reading until it returns EAGAIN
. When it needs to write out data, write the data to fd until all the data is written, or write returns EAGAIN
. When the EPOLLOUT event arrives, continue to write the data to fd until all the data is written, or the write returns to EAGAIN

. As can be seen from the processing of ET, the requirement of ET is to keep reading and writing until it returns to EAGAIN, otherwise it will Missing events. In the processing process of LT, it is not a hard requirement to return to EAGAIN, but the usual processing process will read and write until it returns to EAGAIN, but LT has one more step of switching the EPOLLOUT event than ET.

The programming of LT is close to poll/select, which is consistent with the
ET programming can be more concise and more efficient in some scenarios, but on the other hand, it is easy to miss events and cause bugs

. Here are two simple examples to demonstrate the usage of LT and ET (where epoll- et's code is 10 lines less than epoll):
https://github.com/yedf/handy/blob/master/raw-examples/epoll.cc
https://github.com/yedf/handy/blob/master/ raw-examples/epoll-et.cc

For the scenario where the LT switch EPOLLOUT event is easily triggered (let the server return 1M data), I used ab to test the performance. The
test results show that the performance of ET is slightly better. The details are as follows:
LT start command ./epoll a
ET start command ./epoll-et a
ab command: ab -n 1000 -k 127.0.0.1/
LT Result: Requests per second: 42.56 [#/sec] (mean)
ET Result: Requests per second: 48.55 [#/sec] (mean)

When I put the server back When the data size is changed to 48576, EPOLLOUT is switched more frequently, and the difference in performance is greater
. ab command: ab -n 5000 -k 127.0.0.1/
LT Result: Requests per second: 745.30 [#/sec] (mean)
ET Result: Requests per second: 927.56 [#/sec] (mean)

For a high-performance server such as nginx, the ET mode is very good, while other general-purpose network libraries use LT more to avoid bugs during use