Как стать автором
Обновить

Комментарии 9

На libevent не смотрели? По тестам здесь — asio ему сильно проигрывает. Ну и кстати асинхронность — не всегда круто — ради интереса запускал ~20к тредов с уменьшенным стеком — норм. Без асинхронности код, как правило, проще.
Отвечу сразу вам и orcy. Признаться такой вариант в голову приходил, не на долго. Все-таки изначально сервер написан на C++ и логично было бы использовать библиотеки, которые что называется «ближе к телу». Наличие инкапсуляции также помогает выйти на некий уровень абстракции и не разбавлять код логики IMAP кодом управления событиями.

Насчет производительности — в этом посте взят пример http server 3 и просто собран «как есть». Способ обработки сами асинхронных событий в нём мне нравится, но вот остальной код кажется не слишком оптимальным. В частности, методы parse/consume в request_parser разбирает пришедшие данные побайтово, а все компоненты запроса кладёт в std::string по буквам, через push_back. Плюс, не учтена особенность strand, о которой говориться в этой статье. В подобных тестах нужно быть более осторожным=) Но конечно, спору нет: зачастую C++ библиотека будет работать медленнее plain-C. Я сторонник мнения, что лучше написать такие вещи быстрее, а сэкономленное время потратить на оптимизации самих алгоритмов, которые обычно «сьедают» больше ресурсов.
Ясно, спасибо за ответ и пост. Ещё было бы интересно почитать про архитектуру всей почты.
А ещё в том коде из тестов для boost::asio есть лишние аллокации памяти — при использовании толстых boost::bind и shared-указателей.
При желании, можно было бы переделать это пример, чтобы показать, что asio не так плох. Но вообще итак понятно, что boost::asio лучший вариант по переносимости, качеству абстракций и сервисов из коробки. Тем более, что тесты, думаю, показали вполне удовлетворительный по скорости результат работы даже неоптимального кода для asio.
libuv — вроде как еще вариант для асихнронного io. Не рассматривали ли его в качестве варианта вместо boost::asio?
Так что я считаю, что в современном мире резонно говорить о проблеме C100K или C1M.
Истинно так. 2010 год, C500K, Java, 2.5GB RAM

Наверно можно было использовать какой-нибудь из существующих опенсурсных IMAP-proxy для «экранирования» от странных клиентов. Nginx кажется это умеет и он сам по себе асинхронный. Вы рассматривали такой вариант?
В случае с SSL всё сложнее. Поддержка одного соединения весьма дорого обходится по памяти, даже если отключить сжатие: одно соединение обычно «кушает» не менее 32К памяти(и это оптимистичный вариант!), если взять 40тыс соединений это уже 1.2Гб памяти. Я бы сказал 100К и 1М — это пороги для SSL/не-SSL соответственно.

Вариант с прокси рассматривали, возможно она могла бы решить часть проблем, но конечно не все. Сделать первую версию на asio оказалось гораздо проще и быстрее, а сам переход решил многие вопросы. Поэтому нужда в прокси пока отпала и решили не усложнять админам жизнь.
Судя по этому (http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/using.html), Вы вряд ли полностью отказались от epoll…
Хочу немного поправить про strand. Отдельные задачи в strand-е могут выполняться в разных потоках, но при этом они не будут выполняться параллельно
Зарегистрируйтесь на Хабре , чтобы оставить комментарий