Привет всем
Нужно написать серверное приложение к которому будит обращаться клиенты.
В общем это информационный сервер который информирует пользователей в локальной сети о каких-то событиях и о остатке на счету.
Клиенских подключений будет 1000. Надо что бы клиентское ПО получало раз в 1-2 минуту информацию (то есть не критично все время вести обмен, можно даже подключился-принял данные-отключился и так каждую минуту-две, при этом сервер сам тогда должен выстраивать очередь подключений ИМХО, то есть сообщать клиентам когда им подключатся :) )...Что посоветуете и что посоветуете почитать по теме разработки серверов?
OS:FreeBSD (или Линух, что в меньшей степени...)Нашел:
1.Подходы к организации серверного приложения(что не сильно отвечает на вопрос как делать сервер)
http://www.opennet.me/base/dev/server_way.txt.html
2.Вот про kqueue/kevent (расширение знаний))) http://www.opennet.me/base/dev/kevent_freebsd.txt.html3.про epoll(расширение кругозора) http://www.opennet.me/base/dev/epoll_example.txt.html
4.Реализация многопотокового "ассинхронного серера TCP" и RPC для ОС Linux (уже ближе к ответам, правда реализация FSM+select) http://www.opennet.me/base/dev/pthread_select_server.txt.html
5.Сокеты(Да позновательно по поводу сокетов, но нет примеров для множества клиентов) http://www.opennet.me/docs/RUS/socket/index.html
6.на англ Я так и не разобрался http://www.kegel.com/c10k.html
OS:FreeBSD (ну или Линукс...)
7.Опять на англ. и Я не смог со всем разобраться... http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html
В чем проблема с 1000 параллельных подключений, кроме необходимости поправить лимиты? Напишите простейшую без всяких задержек реализацию на скриптовом языке, например perl, и посмотрите как оно будет функционировать.
>В чем проблема с 1000 параллельных подключений, кроме необходимости поправить лимиты? Напишите
>простейшую без всяких задержек реализацию на скриптовом языке, например perl, и
>посмотрите как оно будет функционировать.Ну..эм...
Я думаю что если к апачу подключатся 500 человек, то уже будет сложненько ему %) И думаю что на перле оно примерно столько же будет хавать %)ЗЫ:
Хочу правильно делать, ибо неправильно можно всегда успеть...
Не надо путать теплое с мягким. Апачу, который принимает соединения, в общем-то по барабану. Вот только на каждое(mod_prefork) соединение порождается потомок, который очень много кушает памяти, особенно с mod_php и подобным. В результате кончается память, но не лимит соединений. Надеюсь вы не собираетесь форкаться на каждое подключение.На практике 500+ одновременных исходящих(особой разницы со входящими в данном случае нет) соединений из перлового скрипта проблемы не составляют, ближе к 1024 начинаем получать отлуп от ядра о невозможности бинда сокета, то бишь утыкаемся в какой-то лимит. Искать переменную за это отвечающую мне было лень, так как нескольких сотен вполне хватало.
в любом случае, что вам мешает написать за полчаса прототип на скриптовом языке и проверить его?
Все выше сказанное не исключает того, что вы упретесь в производительность процессора или пропускную способность сетевой карты. Но это уже совсем другая задача.
Если у вас есть желание, а у меня будет время, то могу даже дать пример клиента(хотя его можно спокойно заменить на ab) и сервера на перле, демонстрирующих работу с большим количеством соединений.
Я про апач почему сказал? Потому что при таком количестве соединений он отъесть дофига памяти, так же и прототип на перле, если просто держать это все в памяти :)
Ну это вам виднее, что вы собираетесь отдавать клиентам и какой объем данных на каждого клиента _всегда_ храните в памяти. При использовании select без тредов разбросанных по физическим процессорам вы в каждый момент времени обслуживаете одного клиента, хотя в целом создается впечатление одновременной обработки.
ну Я понял тоже так:)
Вот только select - медленно, ну ладно заменем на kq*, но вся проблема в том, что данные хранятся в ДБ, а это значит что если будут блокировки со стороны неё то всё будет тормозит(это Я про FSM-модель)...
Ладно - это чисто теория, которую Я вроде понял, а вот где почитать практику?...В этом вопрос
>вся проблема в том, что данные хранятся в ДБ, а это значит что если будут блокировки со стороны неё то всё будет тормозит(это Я про FSM-модель)Типа в других моделях база волшебным образом ускорится. Кроме того что мешает использовать select и для БД? Ну и memcached может быть полезным.
>Ладно - это чисто теория, которую Я вроде понял, а вот где почитать практику?...В этом вопрос
Вы же в начальном посте перечислили ссылки с описанием методов, вопрос у вас был только в количестве соединений, так чего вам еще надо?
>На практике 500+ одновременных исходящих(особой разницы со входящими в данном случае нет)
>соединений из перлового скрипта проблемы не составляют, ближе к 1024 начинаем
>получать отлуп от ядра о невозможности бинда сокета, то бишь утыкаемся
>в какой-то лимит.именно бинда сокета или его создания?
сами сокеты это те же дескрипторы и на них распространяется ulimit -n (равный обычно 1024).
>>На практике 500+ одновременных исходящих(особой разницы со входящими в данном случае нет)
>>соединений из перлового скрипта проблемы не составляют, ближе к 1024 начинаем
>>получать отлуп от ядра о невозможности бинда сокета, то бишь утыкаемся
>>в какой-то лимит.
>
>именно бинда сокета или его создания?
>сами сокеты это те же дескрипторы и на них распространяется ulimit -n
>(равный обычно 1024).ПАМЯТЬ и процессор
>>именно бинда сокета или его создания?
>>сами сокеты это те же дескрипторы и на них распространяется ulimit -n
>>(равный обычно 1024).
>
>ПАМЯТЬ и процессорэто к чему вообще?
Не помню уже, вполне возможно что из-за лимита дескрипторов, мне было неинтересно :)
>
>6.на англ Я так и не разобрался http://www.kegel.com/c10k.htmlВ этом обязательно разберись.
Ну и, традиционно, libevent - http://monkey.org/~provos/libevent/