Anatoly MoskovskyПоток на каждое соединение - это не масштабируется на большое число соединений.
Нужна архитектура, где небольшое число потоков (к примеру равное числу процессоров) обслуживают каждый большое число соединений.
Тут как бы неминуемо приходим к асинхронному выполнению операций над сокетами, что предусматривает разбиение логики программы на множество колбэков - приготовьтес к этому, код станет запутанней чем с потоками, это плата за масштабируемость.
Соответственно нужно выбрать библиотеку которая в полной мере поддерживает асинхронность и многопоточность.

libevent - хороший выбор, если у вас на чистом С приложение.

Если же у вас С++, то рекомендую не заморачиваться и использовать Boost.Asio
Вот пример простого ECHO сервера на нем
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/echo/async_tcp_echo_server.cpp
Там один поток, но несложно переделать в несколько потоков, чтобы использовать все ресурсы сервера.

Вот полноценный HTTP сервер, который уже с потоками
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/server2/
А в Boost.Asio до сих пор используются обычная MP-MC очередь на mutex, для распределения дескрипторов "готовых" сокетов полученных при демультиплексировании select/kqueue/epoll - не поставили туда ещё boost::lockfree::queue<>, который быстрее в 2 раза, или не сделали там возможность настройки пакетного распределения - batch-инга?

Anatoly MoskovskyВася Уткин,

Если использовать схему "один io_service - один поток", то неважно какая там очередь, потоки не конкурируют между собой, а замыкание мютекса при отсутствии конкуренции это и есть lock-free :)
А это оптимальная схема с точки зрения производительности - на один порт вешать несколько io_service-ов, и использовать на каждый "один io_service - один поток"?

Anatoly MoskovskyВася УткинА это оптимальная схема с точки зрения производительности - на один порт вешать несколько io_service-ов, и использовать на каждый "один io_service - один поток"?
Ну, на один порт не повесишь несколько сервисов.
Там висит один отдельный сервис+поток, и он уже равномерно раскидывает новые соединения по пулу сервисов.
Я так понимаю это - "отдельный сервис+поток, и он уже равномерно раскидывает новые соединения по пулу сервисов" скрыто за самой библиотекой Boost.Asio.
А в моем коде будет выглядеть именно как несколько сервисов на одном порту?

Anatoly MoskovskyТ.е. конкуренция между потоками есть - в момент создания нового соединения, но это имеет несущественное значение, т.к. основная работа с сервисом происходит все-таки в одном потоке и плюс конкурируют не более чем 2 потока.
В смысле, какие 2 потока конкурируют, если и сервис и обработчик в одном потоке?

sherzod_Anatoly Moskovsky,

можно привести пример передачи сокета в другой io_service?
http://alexott.net/ru/cpp/BoostAsioNotes.html
автор test-mcmt.cpp — реализует обработку данных в соответствии со стратегией Many Connections/Many Threads: запускается несколько нитей выполнения, которые по очереди принимают соединение и обрабатывают запросы в асинхронном режиме;
Из начала очереди io_service переставляется в конец, по принципу round-robin: https://github.com/alexott/boost-asio-examples/blob/master/test-mcmt.cpp#L130

В потоке акцептора создается сокет в составе объекта connection, который передается текущему io_service: https://github.com/alexott/boost-asio-examples/blob/master/test-mcmt.cpp#L133

Anatoly MoskovskyПоток accept добавляет хендлер в очередь одного из сервисов в пуле, дальше все хендлеры добавляются уже из потока этого же сервиса. Т.е. конкуренция идет за очередь сервиса в момент accept.
Anatoly MoskovskyТ.е. конкуренция между потоками есть - в момент создания нового соединения, но это имеет несущественное значение, т.к. основная работа с сервисом происходит все-таки в одном потоке и плюс конкурируют не более чем 2 потока.
Но ведь в случае с web-сервером, например, каждый вызов страницы - это открытие и закрытие нового соединения. А если на web-сервере страницы статичные и быстро создаются, то нельзя сказать, что "основная работа с сервисом происходит все-таки в одном потоке" по сравнению с засыпанием acceptor-a на мьютексе и ожидания пока он снова проснется, ведь пока acceptor спит ни одно новое соединение не может быть создано.

MasterZivВася УткинНо ведь в случае с web-сервером, например, каждый вызов страницы - это открытие и закрытие нового соединения.


Вовсе не обязательно. Есть keep-alive.

Вася Уткин А если на web-сервере страницы статичные и быстро создаются, то нельзя сказать, что "основная работа с сервисом происходит все-таки в одном потоке" по сравнению с засыпанием acceptor-a на мьютексе и ожидания пока он снова проснется, ведь пока acceptor спит ни одно новое соединение не может быть создано.

Переведи ...
Что непонятно, что эта очередь на мьютексе?Anatoly Moskovsky Поток accept добавляет хендлер в очередь одного из сервисов в пуле...
Или что поток accept может на этом мьютексе заснуть (переключится контекст в ожидании освобождения мьютекса)?
Или что поток accept ожидающий мьютекса не может принимать соединения?

MasterZivВася Уткин,

Я в упор тебя не понимаю.

Этот accept ?

http://msdn.microsoft.com/en-us/library/windows/desktop/ms737526(v=vs.85).aspx
(или его POSIX-аналог)

Почему он должен висеть на мьютексе ?
Потому что надо читать сначала - мы говорим про Boost.Asio :) и в нем вызов async_write/async_read - это добавление хендлера в мьютексную очередь. Мы говорим не про функцию accept, а про весь поток-acceptor, который создает сокет, вызывает accept и отдает этот сокет в один из потоков в пуле.

Anatoly Moskovsky Поток accept добавляет хендлер в очередь одного из сервисов в пуле...
Когда Поток accept вызывает async_write/async_read - добавляет в мьютексную очередь, а один из сервисов в одном из потоков из пула потоков читает из этой очереди в хендлер для исполнения, что происходит?

MasterZivПо-моему так всё просто:

Висишь на select-е (или poll/epoll) . Владеешь всеми хендлерами сокетов.

select генерирует событие.

по всем сработавшим сокетам (по каждому) создаём задачу на обработке в пуле коннектов,
хватаем мьютекс очереди, пихаем задачи в очередь, отдаём мьютекс. Отдаными сокетами более не владеем.

Взводим event/semaphore, что есть задачи.

потоки пула просыпаются, каждый хвать мьютекс, хвать себе задачу. Отдать мьютекс и делать задачу (обрабатывать запрос).

Если нужна новая задача, порождаемая обработкой, -- тот же механизм.

Верно. На большом количестве коротких соединений оптимальнее использовать lock-free очередь вместо lock-based(mutex) очереди, но почему не используют в Boost.Asio?