Комментарии 9
На libevent не смотрели? По тестам здесь — asio ему сильно проигрывает. Ну и кстати асинхронность — не всегда круто — ради интереса запускал ~20к тредов с уменьшенным стеком — норм. Без асинхронности код, как правило, проще.
0
Отвечу сразу вам и orcy. Признаться такой вариант в голову приходил, не на долго. Все-таки изначально сервер написан на C++ и логично было бы использовать библиотеки, которые что называется «ближе к телу». Наличие инкапсуляции также помогает выйти на некий уровень абстракции и не разбавлять код логики IMAP кодом управления событиями.
Насчет производительности — в этом посте взят пример http server 3 и просто собран «как есть». Способ обработки сами асинхронных событий в нём мне нравится, но вот остальной код кажется не слишком оптимальным. В частности, методы parse/consume в request_parser разбирает пришедшие данные побайтово, а все компоненты запроса кладёт в std::string по буквам, через push_back. Плюс, не учтена особенность strand, о которой говориться в этой статье. В подобных тестах нужно быть более осторожным=) Но конечно, спору нет: зачастую C++ библиотека будет работать медленнее plain-C. Я сторонник мнения, что лучше написать такие вещи быстрее, а сэкономленное время потратить на оптимизации самих алгоритмов, которые обычно «сьедают» больше ресурсов.
Насчет производительности — в этом посте взят пример http server 3 и просто собран «как есть». Способ обработки сами асинхронных событий в нём мне нравится, но вот остальной код кажется не слишком оптимальным. В частности, методы parse/consume в request_parser разбирает пришедшие данные побайтово, а все компоненты запроса кладёт в std::string по буквам, через push_back. Плюс, не учтена особенность strand, о которой говориться в этой статье. В подобных тестах нужно быть более осторожным=) Но конечно, спору нет: зачастую C++ библиотека будет работать медленнее plain-C. Я сторонник мнения, что лучше написать такие вещи быстрее, а сэкономленное время потратить на оптимизации самих алгоритмов, которые обычно «сьедают» больше ресурсов.
+8
А ещё в том коде из тестов для boost::asio есть лишние аллокации памяти — при использовании толстых boost::bind и shared-указателей.
При желании, можно было бы переделать это пример, чтобы показать, что asio не так плох. Но вообще итак понятно, что boost::asio лучший вариант по переносимости, качеству абстракций и сервисов из коробки. Тем более, что тесты, думаю, показали вполне удовлетворительный по скорости результат работы даже неоптимального кода для asio.
При желании, можно было бы переделать это пример, чтобы показать, что asio не так плох. Но вообще итак понятно, что boost::asio лучший вариант по переносимости, качеству абстракций и сервисов из коробки. Тем более, что тесты, думаю, показали вполне удовлетворительный по скорости результат работы даже неоптимального кода для asio.
+3
libuv — вроде как еще вариант для асихнронного io. Не рассматривали ли его в качестве варианта вместо boost::asio?
0
Так что я считаю, что в современном мире резонно говорить о проблеме C100K или C1M.Истинно так. 2010 год, C500K, Java, 2.5GB RAM
Наверно можно было использовать какой-нибудь из существующих опенсурсных IMAP-proxy для «экранирования» от странных клиентов. Nginx кажется это умеет и он сам по себе асинхронный. Вы рассматривали такой вариант?
0
В случае с SSL всё сложнее. Поддержка одного соединения весьма дорого обходится по памяти, даже если отключить сжатие: одно соединение обычно «кушает» не менее 32К памяти(и это оптимистичный вариант!), если взять 40тыс соединений это уже 1.2Гб памяти. Я бы сказал 100К и 1М — это пороги для SSL/не-SSL соответственно.
Вариант с прокси рассматривали, возможно она могла бы решить часть проблем, но конечно не все. Сделать первую версию на asio оказалось гораздо проще и быстрее, а сам переход решил многие вопросы. Поэтому нужда в прокси пока отпала и решили не усложнять админам жизнь.
Вариант с прокси рассматривали, возможно она могла бы решить часть проблем, но конечно не все. Сделать первую версию на asio оказалось гораздо проще и быстрее, а сам переход решил многие вопросы. Поэтому нужда в прокси пока отпала и решили не усложнять админам жизнь.
+6
Судя по этому (http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/using.html), Вы вряд ли полностью отказались от epoll…
0
Хочу немного поправить про strand. Отдельные задачи в strand-е могут выполняться в разных потоках, но при этом они не будут выполняться параллельно
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
IMAP на boost::asio