Есть ли какая-либо польза от использования epoll с очень небольшим количеством файловых дескрипторов?

Question

Может ли следующее однопоточное клиентское приложение UDP видеть преимущество производительности при использовании epoll вместо простого вызова recvfrom/sendto на неблокирующих сокетах?

Позвольте мне объяснить клиента.

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

Если я использую epoll, будет ограниченное число, возможно, 10-20 дескрипторов файлов, которые epoll_wait может ждать. Каждый дескриптор файла будет связан с одним сеансом. Таким образом, это максимум 10-20 сеансов, и это число будет соблюдено.

У каждой сессии есть свой государственный автомат. Из одного потока мне нужно регулярно запускать каждый конечный автомат и опросить соответствующий сокет.

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

Однако, я не могу увидеть большую пользу этого дизайна при таком небольшом количестве дескрипторов файлов.

Как я вижу, у меня есть два варианта дизайна: 1. В моем основном цикле, использующем epoll, я могу опросить дескрипторы, используя epoll_wait с небольшим таймаутом или без таймаута.

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

Или ... 2, Просто запустите каждый конечный автомат из основного контура и вызовите recvfrom. Если я получу некоторые данные, обработайте их. Если я не буду делать то, что требуется государственному автору. Есть ли огромные накладные вызовы, когда нет данных?

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

Любые мысли?

Answer 1

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

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