С помощью одного файлового дескриптора существует ли разница в производительности между select, poll и epoll и ...?

название действительно говорит все это.

и ... средства также включают pselect и ppoll..

серверный проект, над которым я работаю, в основном структурирован с несколькими потоками. Каждый поток обрабатывает один или несколько сеансов. Все нити идентичны. Протокол заботится о том, в каком потоке будет проходить сеанс.

Я использую внутренний класс сокета, который завершает вещи. Точкой интереса является вызов checkread, который вызывает либо poll (linux), либо выберите (окна).

в сводке каждый поток в настоящее время вызывает опрос на одном сокете. Из того, что я могу сказать, использование epoll было бы только полезно, если бы этот поток смотрел на несколько сокетов, таких как то, что вы получите, скажем, HTTP-сервер. Это не то, что я делаю в моем случае. И класс обрабатывает только один сокет за раз.

существует некоторое краткое обсуждение о запуске edge и level в man-страницах для epoll. Я не совсем понимаю, что это значит. В класс сокета я вижу оптимизацию в части кода windows, которая сокращает вызов select с помощью ioctlsocket & FIONREAD, чтобы проверить, есть ли какие-либо данные. Интересно, будет ли это возвращать > 0, даже если полный пакет UDP не прибыл во время вызова. Это то, что вызывает edge в epoll?

в некоторых рудиментарных тестах я также не вижу заметной разницы между использованием select и poll.

Я вижу, что использование ppoll может принести пользу хотя из-за большей точности в аут. Есть мысли?

и да, я пытаюсь оптимизировать пропускную способность для сеанса, который получает много данных. Сервер больше связан с сетью и диском, чем CPU.

12
c++ epoll select sockets

3 ответов

основное различие между epoll vs select или poll заключается в том, что epoll масштабируется намного лучше при запуске в одном потоке. Я не знаю, как это сравнить с использованием многопоточного сервера с помощью select или poll. Посмотри на это http://monkey.org/~provos/libevent/libevent-benchmark2.jpg

причина этого (насколько я могу судить) заключается в том, что при использовании select или poll вы должны перебирать все подключенные сокеты, чтобы определить, какие из них имеют данные для чтения. Когда вы используете epoll, он сохраняет отдельный массив, который содержит ссылки только на сокеты, которые имеют данные для чтения. Это сохраняет вас серии циклов петли, и разница будет больше и больше заметной больше гнезд которые соединены.

еще одна вещь, которую нужно изучить, если производительность когда-либо станет серьезной проблемой, - это порты завершения ввода-вывода(только windows) и kqueue(только FreeBSD). Также важно помнить, что epoll-это только Linux. В большинстве случаев select или poll будут работать только штраф.

в случае одного файлового дескриптора select и poll более эффективны, чем epoll из-за того, что намного проще. (epoll имеет некоторые накладные расходы, которые не делают себя полезными только с одним сокетом)

5

по ссылке:http://www.intelliproject.net/articles/showArticle/index/io_multiplexing.

если вы используете только один дескриптор:

  • select: 201 микро-секунд.
  • poll: 159 микро-секунд.
  • epoll: 176 микро-секунд.

кажется poll будет лучшим решением в такой ситуации.

4

Если у вас есть только один сокет, в чем смысл опроса в первую очередь? Не будет ли лучшей производительностью просто использовать блокировку чтения / записи?

Wrt. производительность, только с одним файловым дескриптором я не думаю, что существует большая разница между различными подходами. Если вы действительно заботитесь, я полагаю, вы могли бы измерить, но я затрудняюсь, что это особенно важно для общей производительности программа.

уровень / край срабатывания. Считайте, что вы контролируете сигнал, для простоты скажите некоторое напряжение в линии. Край срабатывания означает, что что-то срабатывает, когда напряжение переходит или под определенным пределом. Уровень запуска означает, что что-то считается в активированном состоянии, пока напряжение превышает/ниже предела. То есть, триггеры запуска edge, когда происходит какое-то событие (пересечение некоторого порога), запуск уровня отражает состояние какая-то" вещь " (в данном случае напряжение).

чтобы вернуться к сетевому программированию, и edge triggered system может быть тем, где вы получаете какой-то сигнал при получении пакета. Если вы не обрабатываете событие, сигнал теряется. Система запуска уровня, OTOH, что-то вроде вопроса "есть ли данные, ожидающие меня в буфере?"; если вы не справитесь с событием и не спросите снова, данные все равно будут ждать вас.

0