Высокопроизводительный сервер с использованием libEvent
Я проектирую высокопроизводительный сервер (не HTTP-сервер) и обдумываю свои варианты дизайна. Сервер должен поддерживать большое количество входящих соединений (в тысячах) и компилировать как на windows, так и на linux.
Что касается окон, я реализовал сервер IO Completion Port, который до сих пор, похоже, справлялся со стрессом. Поскольку спрос на Linux вырос, я сейчас пытаюсь найти кроссплатформенную библиотеку, которая дает мне возможность использовать события accept / read с пулом потоков.
Пока что libEvent кажется правильным выбором (что-то вроде «Пример кода: эхо-сервер» в этом ссылка на сайт). Но цитируя другая страница в документации libEvent:
Если event_base настроен на использование блокировки, доступ к нему безопасен
между несколькими потоками. Его цикл может быть запущен только в одном потоке,
тем не мение. Если вы хотите, чтобы несколько потоков опрашивали IO, вам нужно
иметь event_base для каждого потока.
Мой основной дизайн — иметь пул потоков, реагирующий на прием и чтение событий. Эта цитата, если я правильно понимаю, говорит, что я не могу этого сделать.
У кого-нибудь есть опыт работы с high-perf. серверы на базе libEvent? Должен ли я использовать другую библиотеку?
Пример кода для такого сервера будет идеальным
Решение
libevent это путь, если вы хотите остаться кроссплатформенным.
Если вы хотите быть высокоэффективным, я бы порекомендовал API для конкретной платформы, такие как порты завершения ввода-вывода (которые у вас работают в Windows) и Epoll в Linux:
Обратите внимание, что libevent использует epoll для Linux в любом случае.
Что касается вашего вопроса о многопоточном дизайне, я надеюсь, что вы не используете один поток для обработки каждого входящего клиентского соединения … вы бы потерпели поражение от цели использования модели, управляемой событиями, если бы вы это сделали! Вы должны разработать свой код так, чтобы несколько клиентских подключений обрабатывались одним потоком, и увеличивать количество потоков по мере увеличения числа одновременных подключений.
Я также не стал бы выполнять какую-либо тяжелую вычислительную работу с данными, которые клиенты отправляют в пул потоков, который выполняет ввод-вывод, получая данные. Я бы разделил задачу выполнения ввода-вывода с интенсивным использованием сети и выполнения любых ресурсоемких вычислений на два отдельных пула потоков
Другие решения
Других решений пока нет …