LINUX.ORG.RU

архитектура сервера [c/c++]


0

0
Доброго времени суток !

Прочитав несколько книг, в том числе У. Стивенс UNIX: разработка сетевых приложений сделал вывод что лучшая реализация сервера - pre forking или содание потока для каждого клиента. Мнение о select, poll осталось не однозначное. Хотя мнение было сугубо эмпирическим. На практике реально использовал select'ом и poll'ом и даже kevent'ом. Но число одновременых соединений было небольшим.

Скоро придется реализовывать прокси-сервер с большим числом коннектов (>=10000). ОС - Linux/FreeBSD.

Посоветуйте и пожалуйста обоснуйте - какую архитектуру сервера использовать - мультиплексорный I/O или все же pre-forking/pre-threading или что то другое.

//используемый язык программриования - c/c++

anonymous
многопоточность - тоже та еще штука. Помойму лучше комбинировать

Может поможешь в соседней теме?

♪♪♪

Motiv_studenta ★★
()
thread-per-client при 10000+ соединений жить не будет, ни на процессах, ни на pthread; особенно под фрей - шедулер сдохнет (не, работать-то оно будет - на неэффективно).

Быстрее всего будет, наверное, либо сочетание пре-форкинга с портабельным мультиплексированием (тselect/poll, но если дескрипторов больше N - то отдаем другому треду), либо системно-специфичное мультиплексирование (kevent, /dev/kpoll и что там еще бывает); причем скорее второе.

anonymous
()
100,000 тредов жить будут -- по этому поводу несколько лет назад ьыл топик в LKML.

Когда-то давно писал прокси сервер: одно соединение -- один тред. понятное дело, работало все очень медленно.

Сейчас работаю с сервером другой архитектуры: pre-forked с N тредами. Между ними шарится очередь из которой они берут задания. Соединения обрабатываются другим тредом через epoll (где-то мне попадался paper по поводу сравнения epoll и select -- только на количестве трeдов больше 1000 или 10000 epoll давал выигрыш). При большем потоке запросов, пускаются еще треды.

lunc ★
()
треды вещь не слишком надежная, тут два пути, либо держать пул форков, либо держать пул форков и у каждого будет свое количевство (не большое) тредов.

полагатся только на треды не стоит.

стоит помнить что треды это не везде треды в том их обычном понимании.

alphex_kaanoken ★★★
()
Ответ на: комментарий от lunc
> 100,000 тредов жить будут -- по этому поводу несколько лет назад ьыл топик в LKML.

Я не говорил, что оно не запустится. Но если у тебя будет 10000 runnable тредов - то проц не будет заниматься ничем, кроме их шедулинга.

anonymous
()
Ответ на: комментарий от anonymous
Для сиих целей есть конкретный язычок, придуманный для всяких там мега-коммутаторов с сотнями тысяч потоков. Вот только название не помню, то ли Erlang, то ли еще как.
e
()
Ответ на: комментарий от e
>Для сиих целей есть конкретный язычок, придуманный для всяких там мега-коммутаторов с сотнями тысяч потоков. Вот только название не помню, то ли Erlang, то ли еще как.

Помойму это и то что мне нужно. Одна трабла-я даже на русском функциональное программирование непойму(хотя неочень пытался). Английский у меня довольно страдает. Кто-нибудь посоветует как выучить Erlang? Азы функционального программирование т.д и т.п

Motiv_studenta ★★
()
при таком количестве одновременных коннэктов тебе вез вариантов надо пользовать симбиоз из пула процессов + epoll OR kevent в противном случае ничего путнего не выйдет. а вообще до недавнего временни задача была оччень нетривиальная.

ЗЫ: интересно а может чем нить асинхронный В/В в этой ситуации помочь?

cvv ★★★★★
()
Ответ на: комментарий от Motiv_studenta
>Помойму это и то что мне нужно.

Точнее задачу опиши, если тупо роутить данные - подойдёт.. если потом начнёшь писать фильтры всякие - не подойдёт. сам когда-то на эрланге что-то вроде прокси делал, потом количество Сишных драйверов к нему росло-росло, и в итоге проще было на Си++ всё переписать..

forgiven
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.