Как оптимальнее организовать оповещения о событиях

← →
Дмитрий С © (2009-07-07 19:38) [0]

Проектируется продукт, который будет использоваться в моей организации. Продукт клиент-серверный, т. е. есть сервер и порядка 1000 подключенных клиентов. Два сегмента сети, примерно по 15% пользователей имеют достаточно медленное подключение (примерно по 2 мегабита на сегмент).
Для использования выбран протокол https, как наиболее оптимальный по ряду причин. В качестве сервера выбран Apache + PHP, так же по ряду причин.
Задача сервера, помимо обработки простых запросов, оповещать клиентов о чем либо. Собственно тут и встает вопрос, каким образом клиенты *своевременно* узнают об этих оповещениях. Есть два варианта, которые приходят на ум:
1. Это регулярные запросы на сервер.
2. Долгие запросы (фактически постоянное подключение).

Подробнее:
1. Регулярные запросы на сервер. К примеру, раз в 30 секунд (а это уже долго) выполняется запрос на сервер, для проверки - не случилось ли чего. В этом случае получаем нагрузку на сеть примерно 2000 запросов в минуту, а это примерно 33 в секунду - в итоге постоянная загрузка сервера.
2. Постоянное подключение. Т.е. клиент в отдельном потоке выполняет запрос на сервер, но сервер не отвечает до тех пор пока не появится какое либо событие. После обработки события, клиент снова создает подключения на сервер и ждет нового события.
Для контроля соединения сервер примерно раз в минуту посылает клиенту NOPE символ, к примеру пробел.
В итоге, получается нагрузка на сервер практически никакая (все потоки обслуживающие эти подключения почти всегда будут находиться в спячке, научить php делать waitforsingleobject + setevent не так сложно). Данный вариант мне более симпатичен, но тут возникает сложный вопрос по поводу того, как Apache будет вести себя при 1000 "висящих" подключений, да еще и под SSL. Для каждого, ведь, потребуется отдельный поток, а 1000 висящих потока держать не хочется.

Возникает еще такие варианты:
3. Оповещать клиентов о событиях широковещательными UDP пакетами. Клиент получает UDP пакет, по его содержимому определяет для него это событие или нет, и если оно для него - делает запрос на сервер. Минусы в том, что не будет возможности работать клиенту вне локальной сети, а также в том, что пакет будет не зашифрован.
4. Организация отдельного HTTP(TCP) сервиса. В данном случае для каждого клиента не создается отдельный поток. Лишь несколько потоков делают select подключенных сокетов, для того чтобы можно было мгновенно обнаружить разрыв соединения со стороны клиента. В принципе, данный сервис можно будет запускать в отдельном потоке процесса apache.

Ваше мнение по поводу данных вариантов? Как вы организовали бы оповещение клиентов в данном случае?

← →
Хитрий Лис (2009-07-07 19:46) [1]

Многа букав...

По тому что прочитал:
2 мегабита на сегмент - это очень быстро. На модеме при 128kb вполне приемлимая скорость.
1. Это регулярные запросы на сервер. - именно этот вариант у меня прекрасно работал, причем как с SQL-сервером, так даже и через почту. Постоянно "слушать" должен кто-то один, в данном варианте это сервер.

← →
DVM © (2009-07-07 19:56) [2]

> Дмитрий С © (07.07.09 19:38)

> Задача сервера, помимо обработки простых запросов, оповещать
> клиентов о чем либо.

Это как раз не задача сервера. Это задача клиента узнать об изменениях.

Я бы первый вариант выбрал. 33 запроса в секунду - это тьфу, а не загрузка.

← →
Zeqfreed © (2009-07-07 20:03) [3]

Второй вариант. Только не понятно зачем Апач :)

← →
DVM © (2009-07-07 20:08) [4]

Второй вариант имхо под IIS лучше.

← →
Zeqfreed © (2009-07-07 20:17) [5]

Что за нравы. Чем Энджинкс не угодил?

"По ряду причин" такая странная отмазка, особенно в виду того, что HTTP для таких операций как-бы не подходит. PHP так вообще не в тему. TomCat ещё куда ни шло. Но такую систему через IRC/SSL организовать всё проще будет.

> Что за нравы. Чем Энджинкс не угодил?

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

> Второй вариант имхо под IIS лучше.

Под IIS можно уже и Com+ без геммороя использовать.

> tesseract © (07.07.09 20:48) [6]

Для высоконагруженных проектов хорошо работает связка nginx + php-fpm. Ну и написать на C, например, FastCGI-бекенд можно, если хочется чтобы все совсем летало.

Как оптимальнее организовать оповещения о событиях Найти похожие ветки