Протесты выбора/опроса по сравнению с epoll реакторами в Скрученном
Все я считал и испытал (Основанные на торнадо приложения) приводит меня полагать, что ePoll является естественной заменой для Выбора и основанных на опросе сетей, особенно со Скрученным. Который делает меня параноидальным, ее довольно редкое для лучшей техники или методологии для не хождения с ценой.
Чтение пары дюжины сравнений между epoll и альтернативами показывает, что epoll является ясно чемпионом для скорости и масштабируемости, конкретно что это масштабируется линейным способом, который является фантастическим. Тем не менее что относительно загрузки процессора и использования памяти, epoll является все еще чемпионом?
1 ответ
Для очень небольшого количества сокетов (конечно, зависит от вашего оборудования, но мы говорим о чем-то порядка 10 или меньше), выберите может превзойти epoll в использовании памяти и скорости выполнения. Конечно, для такого небольшого количества сокетов оба механизма работают настолько быстро, что в подавляющем большинстве случаев вас не волнует эта разница.
Одно уточнение. И select, и epoll масштабируются линейно. Однако большая разница в том, что API-интерфейсы, ориентированные на пользовательское пространство, имеют сложности, основанные на разных вещах. Стоимость вызова select примерно соответствует значению переданного ему файлового дескриптора с самым большим номером. Если вы выберете на одном fd, 100, то это примерно в два раза дороже, чем на одном fd, 50. Добавление большего количества fd ниже самого высокого не совсем бесплатно, поэтому на практике это немного сложнее, но это - хорошее первое приближение для большинства реализаций.
Стоимость epoll ближе к количеству файловых дескрипторов, на которых действительно есть события. Если вы отслеживаете 200 файловых дескрипторов, но только 100 из них имеют события, то вы (очень грубо) платите только за эти 100 активных файловых дескрипторов. Именно здесь epoll предлагает одно из своих основных преимуществ перед select. Если у вас есть тысяча клиентов, которые в основном простаивают, то, используя select, вы все равно платите за всю тысячу из них. Однако с epoll это похоже на то, что у вас их всего несколько - вы платите только за те, которые активны в любой момент времени.
Все это означает, что epoll приведет к меньшей загрузке ЦП для большинства рабочих нагрузок. Что касается использования памяти, это немного не так. select действительно удается представить всю необходимую информацию в очень компактном виде (один бит на дескриптор файла). А ограничение FD_SETSIZE (обычно 1024) на количество файловых дескрипторов, которые вы можете использовать с select , означает, что вы никогда не потратите более 128 байт на каждый из трех наборов fd, которые вы можете использовать с select (чтение, запись, исключение). По сравнению с этими 384 байтами, epoll - своего рода свинья. Каждый файловый дескриптор представлен многобайтовой структурой. Однако в абсолютном выражении он по-прежнему не будет использовать много памяти. Вы можете представить огромное количество файловых дескрипторов несколькими десятками килобайт (я думаю, примерно 20 КБ на 1000 файловых дескрипторов). И вы также можете добавить тот факт, что вам нужно потратить все 384 из этих байтов с помощью select , если вы хотите отслеживать только один файловый дескриптор, но его значение оказывается 1024, тогда как с epoll вам нужно только потратить 20 байт. Тем не менее, все эти цифры довольно малы, поэтому особой разницы нет.
И еще одно преимущество epoll, о котором вы, возможно, уже знаете, - это то, что он не ограничивается файловыми дескрипторами FD_SETSIZE. Вы можете использовать его для отслеживания любого количества файловых дескрипторов. И если у вас есть только один файловый дескриптор, но его значение больше FD_SETSIZE, epoll работает и с ним, а select - нет.
Случайно недавно я обнаружил один небольшой недостаток epoll по сравнению с select или poll . Хотя ни один из этих трех API не поддерживает обычные файлы (то есть файлы в файловой системе), select и poll представляют этот недостаток поддержки, сообщая, что такие дескрипторы всегда доступны для чтения и записи. Это делает их непригодными для любого значимого вида неблокирующего ввода-вывода файловой системы, программа, которая использует select или poll и случайно обнаруживает файловый дескриптор из файловой системы, по крайней мере, продолжит работу. работать (или, если он выйдет из строя, этого не произойдет из-за select или poll ), хотя, возможно, это не с лучшей производительностью.
С другой стороны, epoll быстро выйдет из строя с ошибкой (очевидно, EPERM ), когда его попросят отслеживать такой файловый дескриптор. Строго говоря, это вряд ли неправильно. Это просто явным образом сигнализирует об отсутствии поддержки. Обычно я приветствую явные условия отказа, но это недокументировано (насколько я могу судить) и приводит к полностью неработающему приложению, а не к тому, которое просто работает с потенциально сниженной производительностью.
На практике я видел это только при взаимодействии с stdio. Пользователь может перенаправить stdin или stdout из / в обычный файл. В то время как раньше stdin и stdout были каналом - отлично поддерживаемым epoll - затем он становится обычным файлом, и epoll громко дает сбой, нарушая работу приложения.