Вариант написания многопоточного сервера - динамические потоки или пул!?

[garryHotDog]

Всем привет! Хочу спросить совет!

  Написал серверное приложение, которое выполняет роль сервера закачки файлов...написал на основе qt'шных примеров - при новом подключении создаю поток - после того как поток отработает он удаляется (вообще fortune server)...все работает нормально, но сильно перегружается проц....появилась идея заранее создать ,например, 400 потоков и запускать свободный поток при новом подключении....

Вопрос - какой из вариантов реализации более оптимальный (память\проц)!? И не "мощная" ли это задача создание нового потока в системе?

[ритт]

а не перебор ли это? полагаю, десятка потоков хватит с головой...

[garryHotDog]

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

[SABROG]

Тоже самое можно сделать и в 10 потоках. Создание новых потоков не плодит количество ядер в системе. Пересмотри архитектуру сервера и сделай так, чтобы все получали равные порции данных не зацикливаясь на каком-то одном клиенте.

[garryHotDog]

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

[Igors]

Если 1 нитка занимается только 1 клиентом - то проблемы не решить, без разницы как запускать нитки.

[Barmaglodd]

Почитай классику http://www.kegel.com/c10k.html. Qt - не лучший выбор для твоей задачи, тема обсуждалась на форуме, и нормальные решения предлагались (если надо c\с++, то libevent и boost::asio).

[ecspertiza]

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

[garryHotDog]

если не ошибаюсь в любой ОС есть ограничение на количество создаваемых потоков одним приложением.

в linux эти ограничения можно снять - редактирую файл /etc/security/limits.conf - параметр nofile!

Почитай классику http://www.kegel.com/c10k.html.

у меня не будет 10k, максимум 400 - это ограничение будет установлено в классе сервера QTcpServer!

оговарюсь сразу - вариант 1 клиент - 1 поток - уже работает....просто жрет много CPU...вот я и предположил, что создав заранее n-ное кол-во потоков - уменьшу использование CPU....если вариант 1 клиент - 1 поток Вы считаете не рациональным подскажите пожалуйста другой - а то уже голову сломал!?....заранее спасибо!

[niXman]

libevent и boost::asio

наверное вы хотели сказать - "libevent или boost::asio"

garryHotDog, 10000 потоков - это тупик. можете даже не начинать реализацию этой архитектуры.
проверял на 4ех ядерном проце - два ядра загруженны на 100% только переключением контекста, при том, что сами потоки ничего не делают, в них вставил просто sleep().
идеальная архитектура, это пул из 4ех(кол-во ядер) потоков и асинхронные операции с сокетом.

[garryHotDog]

Мне не нужно 10000 потоков!!!! мне нужно максимум 300-400....

и асинхронные операции с сокетом.

попробую...но по своему опыту могу сказать - что асинхронные сокеты -сильно хавают проц!!

[BRE]

Мне не нужно 10000 потоков!!!! мне нужно максимум 300-400....

попробую...но по своему опыту могу сказать - что асинхронные сокеты -сильно хавают проц!!

А 300-400 потоков, которые просто переключаются и пытаются впихнуть данные в сокет не готовый к отправки из-за медленного клиента, процессор не хавают. 

[garryHotDog]

пробовал 100 - держится в районе 10-20%!!!

[BRE]

пробовал 100 - держится в районе 10-20%!!!

Это не оценка. 
Для таких задач нужно проводить очень тщательное и разностороннее тестирование. Причем как на быстрых, так и на медленных клиентах.
Представь ситуацию, медленный клиент не успевает забирать данные, но процессор переключается на нить, которая его обслуживает. В ней происходит попытка впихнуть очередные данные в сокет, ОС рисует болт. Процессорное время на это расходуется, на переключение - расходуется. Происходит куча операций для абсолютно не нужных действий. В тоже время быстрые клиенты простаивают. Не рационально.

[garryHotDog]

т.е. как я понял - самый оптимальный вариант это асинхронные сокеты? так?