TCP-сервер с boost::asio, масштабируемость пула потоков по сравнению с бесстековыми сопрограммами
Я создаю демон на основе TCP для предварительной и последующей обработки HTTP. Запросы. Клиенты будут подключаться к Apache HTTPD (или IIS), а специальный модуль Apache/IIS будет перенаправлять запросы моему демону TCP для дальнейшей обработки. Мой демон должен будет масштабироваться (но не уменьшаться) для обработки значительного трафика, а большинство запросов будут небольшими и недолговечными. Демон будет построен на C++ и должен быть кроссплатформенным.
В настоящее время я присматриваюсь к библиотекам boost asio, которые кажутся мне естественными.Однако у меня возникли проблемы с пониманием достоинств шаблона сопрограмм без стека и пула потоков. В частности, я рассматриваю пример HTTP-сервера № 3 и пример HTTP-сервера № 4 здесь: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html
. ] Несмотря на все мои поиски в Google, я не могу полностью понять достоинства сервера сопрограмм без стека и того, как он будет работать по сравнению с сервером пула потоков в многоядерной системе.
Какой из двух наиболее подходит для моих требований и почему? Пожалуйста, не стесняйтесь «тупить» свои ответы относительно идеи бесстековой сопрограммы, я все еще нахожусь здесь на шаткой почве. Спасибо!
Изменить: Еще одна случайная мысль/проблема для обсуждения: Пример #4 HTTP-сервера Boost описан как «однопоточный HTTP-сервер, реализованный с использованием бесстековых сопрограмм». Итак, он полностью однопоточный (правильно? Даже после того, как родительский процесс «разветвляется» на дочерний? См. server.cpp в примере № 4) ... станет ли один поток узким местом в многоядерной системе? Я предполагаю, что любые блокирующие операции предотвратят выполнение всех других запросов. Если это действительно так, то для максимизации пропускной способности я думаю об асинхронном событии получения данных на основе сопрограммы, пуле потоков для моих внутренних блокирующих задач (для использования нескольких ядер), а затем об асинхронном механизме отправки и закрытия соединения. Опять же, масштабируемость имеет решающее значение. Есть мысли?