Насчет использования пулов.

стратегию io_service per cpu можно использовать, если одна сессия часто обращается к одним и тем же данным, что-бы кэширование имело смысл, и при этом не выполняет ничего тяжелого. Под тяжелым я имею ввиду продолжительные вычисления, если одна сессия займет процессора на 1мс то ни одна другая сессия, выполняемая на этом io_service-е не сможет ничего сделать в течении этой милисекунды. А в случае пулла потоков это не так, одна из сессий заняла поток на 1мс, все остальные продолжают работать на оставшихся N потоках.


Для того, что-бы это было похоже на SEDA нужно еще много чего сделать  Вообще, хотелось бы узнать какую задачу пытается решить ТС.


Что-бы об этом рассуждать, нужно хоть что-нибудь знать о проблеме. Может быть не победит, может быть вообще победит thread per session 

Добавлено через 1 минуту и 48 секунд
вообще, если клиентов не много, то асинхронный сервер будет иметь более низкую пропускную способность, нежели простой thread per client сервер выполняющий все операции ввода/вывода синхронно, ибо во втором случае будет меньше системных вызовов

"staged event-driven architecture" ?

Не путаем исходящие TCP соединения и входящие 8)
Кол-во входящих ограничено ресурсами ОС (и локальный порт у них у всех один - тот с которого соединение было accepted, т.е. тот, что у listening socket). 
Кол-во исходящих соединений ограничено еще и максимальным кол-вом открытых портов, которых всего м/б 65536 за минусом специальных/занятых другими/не выделяемых под исходящие соединения.
Вот. Заодно и вспомнил теорию.

Добавлено @ 10:27

Конечно, предполагается, что тяжелой работой будет заниматься другой пул потоков.

Добавлено @ 10:28

Да

Добавлено @ 10:31

Естественно, это далеко от SEDA в том виде, как она описана в теории. Но смысл аналогичный - разбиваем обработку на стадии. На каждой стадии м/б свой пул потоков.

Добавлено @ 10:33

Опять, "естественно" да. Эта теория проштудирована много раз. Все же, думаю, здесь рассматривается случай с (большим) множеством клиентов.

Это сообщение отредактировал(а) mabrarov - 21.10.2011, 10:36

Спасибо за пояснения!



Там я указал:


Можно сказать ресерч возможностей каждой из моделей, чтобы иметь информацию для выбора под конкретные требования..



Да. Моя вина - изначально не четко сформулировал вопрос..

Это сообщение отредактировал(а) rumit7 - 21.10.2011, 10:40

Оформить бы выводы в виде FAQ и засунуть в документацию Asio.

все равно это сложнее, нужно решить проблему балансирования нагрузки между отдельными io_service-ами


большой - понятие растяжимое

О том я и писал в своем первом сообщении.

На счет архитектуры. Мало и, возможно, не то, что нужно было. Но интересно.

Спасибо за ссылку!

Я пока обнумываю все то, что здесь говорилось. В принципе есть идея того, как используя memory pool ускорить выделение памяти и помочь стратегии io_service per cpu в плане кеширования.. Есть ряд проблем, если удастся достичь положительного результата - отпишусь здесь.. Если нет, наверно промолчу, умнее казаться буду))

Модератор: хочу отметить высокий профессионализм участников темы - и пожелать им еще больших успехов в нашем непростом сетевом программировании