Принципы построения многопоточного сервера

[Urvin]

Здравствуйте!

Подскажите, пожалуйста, как стоит реализовать оптимальный многопоточный сервер?

- Сервер будет держать около 50 клиентов постоянно подключенными;
- Общение происходит текстовыми строками в xml-подобном варианте. В основном по принципу запрос-ответ, но также сервер может рассылать команды самостоятельно, в т.ч. по запросу одного из клиентов;
- Необходима графическая среда для отслеживания ошибок и управления подключениями;
- В основном, в сервере сосредоточена несложная логика системы, но много SQL-запросов.

На примере fortune server и своих домыслов я бы сделал так:
1. Основной поток - для UI
2. В дополнительном потоке вертится постоянно слушающий порт QTcpServer и диспетчер подключений
3. Как только создается новое подключение, создается новый поток и новый сокет перенаправляется туда.
4. В потоке, обслуживающем сокет создается отдельное подключение к базе данных

Читая различные материалы, я понял, что это достаточное избыточное решение, слишком много потоков.
Как сделать правильно? Какова общая архитектура сервера?

[andrew.k]

для 50 клиентов наверное по фигу как реализовывать.
А так на форуме уже много раз поднималась подобная тема. Правда все разбросано по темам.

[Urvin]

Именно что все разбросано.
Не выходит в голове построить оптимальную модель.
Да, 50 клиентов - не так и много, но хочется же сделать правильно.

[andrew.k]

Именно что все разбросано.
Не выходит в голове построить оптимальную модель.
Да, 50 клиентов - не так и много, но хочется же сделать правильно.

В целом идеология поток на соединение избыточна.
Поэтому один поток должен обслуживать некоторое количество соединений (пул соединений).
А какое количество соединений оптимально на один поток мне неизвестно)
Видимо нужно делать это параметром и смотреть как себя ведет сервер в нагрузке.

[merke]

Ну так и создавай один поток коммуникатор, который занимается обслуживанием клиентов, а второй обработчик, который и занимается рутинной работой - обработка информации, получил что то, поставил в очередь, отдал потоку обработчика, принимаешь другие запросы, как только поток обработчик что то выполнил он передает потоку коммуникатору результат.

[merke]

Просто видишь, сколько потоков не мути, количество процессоров у тебя не увеличится) а количество оперативной памяти на их обслуживание увеличится. Так что смысла в 100500 потоках не вижу, тут достаточно 3-х: главный - уи, 2-й коммуникатор, 3-й обработчик. И будет счастье, для синхронизации работы, или использовать стандартные средства для реализации очередей, либо писать свой класс очереди, под свои нужды(специфические форматы данных).

[Fregloin]

Есть смысл использовать плавающий пул потоков

[merke]

Есть смысл использовать плавающий пул потоков

можно поподробнее об этом?