epoll vs select для очень небольшого количества соединений

Question

Я использовал select для обработки соединений, недавно произошло изменение, и наша библиотека сокетов была заменена на epoll для платформы linux.

моя архитектура приложения такова, что я делаю только один или максимум2 сокетных соединения и epoll / select на них в один поток.

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

имеет ли epoll снижение производительности с точки зрения скорости, если используется для очень небольшого числа сокетов (например, 1 или 2).

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

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

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

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

Спасибо

Привет,

Обновление этого вопроса на последних находках, кромеот переключения от выбора к epoll, я обнаружил другое относительное изменение, более раннее время ожидания с выбором было 10 миллис, но с epoll время ожидания намного меньше, чем раньше (например, 1 мкр.), может установить слишком малое время ожидания в результате выбора или результат epoll при уменьшениипроизводительность в любом случае?

спасибо

Answer 1

Судя по звукам, пропускная способность может не зависеть от epoll() против select(), но вы обнаружите дополнительную задержку в отдельных запросах, которая, по-видимому, связана с использованием epoll().

Я думаю, что в случае просмотра только одного или двух сокетов, epoll() должен работать так же, как select(). Предполагается, что epoll() линейно масштабируется при просмотре большего количества дескрипторов, тогда как select() плохо масштабируется (и может даже иметь жесткое ограничение на # / descriptors). Так что это не значит, что epoll() имеет штраф за небольшое количество дескрипторов, но в этом случае он теряет преимущество в производительности по сравнению с select().

Можете ли вы изменить код, чтобы можно было легко переключаться между двумя механизмами уведомления о событиях? Получите больше данных о разнице в производительности. Если вы окончательно обнаружите, что select() имеет меньшую задержку и одинаковую пропускную способность в вашей ситуации, то я просто переключился бы на «старый и устаревший» API без колебаний :) Для меня это довольно убедительно, если вы измерите разницу в производительности с этой конкретное изменение кода. Возможно, предыдущее тестирование epoll() против select() было сосредоточено на пропускной способности в сравнении с задержкой отдельных запросов?