C: epoll и многопоточность

проверьте libevent и libev. они легко читаются и уже представляют собой хорошую инфраструктуру для использования.

Кроме того, в документации libev есть множество примеров нескольких проверенных стратегий. Даже если вы предпочитаете писать напрямую epoll(), примеры могут привести к некоторым выводам.

..моя идея следующая: создать несколько потоков с собственными дескрипторами epoll, основной поток принимает соединения и распределяет их между потоками epoll.

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

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

Второй вариант — это то, как это делает Apache2, используя пул блокирующих потоков. Здесь нет обработки событий, поэтому реализация проще, а пул означает, что потоки не создаются и не уничтожаются без необходимости, но он не может реально конкурировать с хорошо реализованным гибридом потока/асинхронности, таким как то, что вы пытаетесь реализовать, или Nginx.

На третьем месте стоит асинхронная обработка событий, такая как Lighttpd или Node.js. Ну, это второй вариант, если вы не выполняете интенсивную обработку на сервере. Но, как упоминалось ранее, один продолжительный цикл while блокирует весь сервер.

Если у вас нет терабитного восходящего канала и вы не планируете обслуживать 10 000 одновременных подключений с одного сервера, забудьте о epoll. Это просто беспричинная непереносимость; poll или даже select тоже подойдет. Имейте в виду, что к тому времени, когда терабитные восходящие каналы и тому подобное станут стандартными, ваш сервер также будет достаточно быстрым, и вам все равно не понадобится epoll.

Если вы просто обслуживаете статический контент, забудьте о потоках и используйте системный вызов Linux sendfile. Это тоже нестандартно, но, по крайней мере, дает огромные преимущества в реальной производительности.

Также обратите внимание, что другие проектные решения (особенно чрезмерная сложность) будут гораздо больше влиять на нагрузку, которую может выдержать ваш сервер. Например, просто посмотрите, как скромный однопоточный однопроцессорный thttpd превосходит Apache и его друзей по производительности на статическом контенте — и, по моему опыту, даже на традиционном динамическом контенте cgi!