Серверный чат. Подключений - порядка 2-3к юзверей.
Linux/pthread/C.

Какую архитектуру сервера стоит выбрать?

Итак. Если берём архитектуру "один поток - одно соединение" получаем большую растрату ресурсов, производительность не самая лучшая. 

Если возьмём ту же архитектуру, но по принципу "один поток - несколько соединений". Как в этом случае будет идти расход памяти и процессора? Как в потоке возможно будет обрабатывать одновременно несколько сокетов?

Если берём событийную архитектуру...Какие библиотеки есть для решения этой задачи (ace для c++).

Вообще, что подскажите при выборе архитектуры? 

Я в Linux пока не селен,но думаю это пригодится!


Это сообщение отредактировал(а) Comm - 19.2.2009, 08:36

с помощью асинхронного I/O  
как это сделать в *nix я не знаю, на твоем месте я бы использовал готовую библиотеку, например boost.asio, либо ACE Framework, еще можно сходить в гугл с запросами: "Reactor pattern", "Proactor pattern"  

boost/ace для с++, у меня С (писал об этом в первом посте)

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

тут
извините за саморекламу   

Извините, но прочитав Ваш форум - не совсем согласен..

Лично для меня ХардКод - это разработка и процессорного ядра и ОСи - САМОСТОЯТЕЛЬНО... а не юзанья готовых решений. Именно это направление даст 
а) больший гимор
б) большую скорострельность
всё остальное - от лукавого. - чиссо моё ИМХО.

отвечаю тут, потому как регистрироваться на вашем чудо сайте НЕВОЗМОЖНО. я лично видать полный даун и не смог ответить на вопрос кода BUIR (вроде)...первый раз такую фигню вижу...(надеюсь в последний) 

Добавлено через 10 минут и 14 секунд

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

возвращаясь к баранам...
понятное дело что чем больше параллельность и больше "мозгов" готовых обрабатывать эту параллельность - тем лучше. к сокетам это так же относится. Т.е. ваша дорога не PP соединения а дайтаграмный. Т.е. уровень UDP и свой аля TCP протокол. Всё остальное - жор ресурсов на стороне сервака при пике нагрузок. Это если свои клиенты. Если стандартные броузеры - то тут либо более тесная интеграция в ядро (что собственно трудности) либо увеличение мощностей на стороне сервака и всё таки TCP соединения. "Уменьшить" нагрузку на сервак мона подключением "стаи" серверов работающих параллельно но с разными IP, при этом перебрасывая на них ридиректы (гляньте например любой поисковик, обратите внимание на его IP адреса - они меняются  при пингах).

если клиенты свои - ну тут поле для творчества. саму обработку на серваке мона делать "по клиентно" или скажем "по задачно" или смешанные варианты. PP соединение - это "по клиентная" обработка. Никто не мешает сдалть и по задачно. И то и то решение можно масштабировать в узких местах.


удачи Вам
(круглый)

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

IO completion ports, паттерн "реактор"

этим можно достигнуть чего угодно, кроме эффективной работы сервера =)

Lazin, ты конечно сделал достаточное количество серверов и т.п., в чем я не сомниваюсь глядя на количество звездочек под твоим аватаром, однако просто так говорить, что эффективности добиться нельзя на твоем месте (и с такими звездочками) я бы не стал (Это несколько "порочит" твою же репутацию т.к. любой пост должен иметь информационное наполнение. В данном случае информации, кроме не аргументированного сообщения о невозможности того, что я написал, нет и в помине). Чтобы мое сообщение не "поделяли" за то же самое я хочу дополнительно сказать Lazin о том, что эфективная работа достижима всегда, когда есть чем управлять и есть цель, ради которой и осуществляется управление. В конкретном примере, попробуй представить как будет работать сервер при одном и том же количестве потоков в случаях малого (например 10) и большого (например 10000) количества клиентов.

К сожалению, это не Винда, и виндовские решения тут не подходят......
Автор написал:
Linux/pthread/C.

fry, вопрос перечитай


теперь твой ответ:

Во первых, в случае неблокирующего I/O, оптимальным будет постоянное количество потоков, если ты увеличишь количество потоков, то процессоров у тебя больше не станет.
Во вторых, твое описание архитектуры приложения понятно только тебе, что должен делать метод exec и почему это должно сработать - загадка. 

Добавлено через 1 минуту и 4 секунды

действительно, к сожалению, судя по всему в "винде" с этим проще   

  а то тему перенесут в религиозные войны 

Добавлено через 4 минуты и 49 секунд
loginrl103


не берем такую архитектуру   сразу откладываем

вот! то что надо, равномерное распределение нагрузки.
Можно так
При запуске - создаем 10, 20, 30 (не актуально) потоков. Каждое сойдинение передаем в потоки по очереди, тем самым распределяя нагрузку.

функции select или poll.

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

если не шибаюсь, в *nix'ах есть аналогичный механизм - pool

Добавлено через 1 минуту и 28 секунд
http://www.citi.umich.edu/techreports/repo...iti-tr-00-4.pdf

Добавлено через 3 минуты и 16 секунд
возмите boost::Asio - там эти механизмы икапсулированны

Lazin, ты сам ответил на свой вопрос:

Я и предложил. К тому, что должен делать метод. Этот метод может как минимум выполнять операции В\В через сокет:

По части количества потоков. Думаю для этого надо иметь ввиду еще и политику планирования их выполнения, хотя конечно надо проверять (в целом это как пример было); ИМХО может зависеть от конкретной ОС. Кстати при такой архитектуре контекст выполнения будет абстрагирован от данных о задаче, что заранее даст возможность развития кода в сторону кластерных систем,а при увеличении количества обрабатываемой информации(файлообмен например) это может быть интересным.
Р.S. "Должно сработать" звучало главным образом относительно небольшого количества данных, обрабатываемых сервером при большом количестве клиентов при архитектуре "один поток - одно соединение".

2 года работает у меня такой сервер.
Держит постоянно 1000 клиентов.
Нагрузка на железо минимальная.
Постоянно шарит по БД размером 15гб.

P.S.
Это я про сервер один поток - одно соединение.

Это сообщение отредактировал(а) Artemon - 16.4.2009, 06:13

Там написано 2000-3000.
3000 потоков на одной машине???  

а почему нет? Правда расходы на каждого клиента большие, каждый поток должен иметь стек, допустим 1Мб, тогда получается 3К потоков, это примерно 3Гб, для современного сервера - не вопрос. Другой ресурс - процессороное время, расходы на работу планировщика задач будут очень большими при такой архитектуре, сколько процентов времени своей работы процессор будет выполнять код планировщика задач я не могу сказать, но могу предположить что много  
Но при небольшом количестве клиентов покатит.

http://www.boost.org/doc/libs/1_38_0/doc/h...o/examples.html
на этой странице есть пример чата(клиент и сервер) использующие boost.asio 

Добавлено через 2 минуты и 5 секунд
правда он там однопоточный  

размер стека 1мб это значение по умолчанию, его можно изменить..а почему нет - так ты сам на свой вопрос ответил  

не понимаю чем не подходит паттерн "реактор"