Комментарии 14
Я немного отстал от web технологий. Скажите, а не будет проще для сервера, если клиент будет опрашивать статичный файл и загружать его только в случае изменения даты создания? В таком варианте мы обмениваемся только заголовками и не держим открытую сессию для каждого клиента.
вы не учитываете того факта, что создание соединения — это тоже нагрузка. в теории намного проще держать открытое соединение и обмениваться изредка небольшими сообщениями, нежели периодически бомбить запросами сервак.
Может все зависит от количества передаваемой информации и количества подключенных клиентов?
Что легче, держать 10 000 одновременных подключений в минуту с помощью php демона для передачи 1кб данных, или с помощью nginx отвечать на запросы тех же 10 000 клиентов раз в 10 секунд заголовками целую минуту, передав каждому один раз 1кб данных?
Кстати, порт 8080 открыт не у 100% клиентов.
Что легче, держать 10 000 одновременных подключений в минуту с помощью php демона для передачи 1кб данных, или с помощью nginx отвечать на запросы тех же 10 000 клиентов раз в 10 секунд заголовками целую минуту, передав каждому один раз 1кб данных?
Кстати, порт 8080 открыт не у 100% клиентов.
В JQueryAJAX так же есть функция ifModified. Можно дергать статичный файл, а не php-скрипт. Можно открыть кучу аналогов сокета на 80-м порту на одном ip. Если не требуется моментальная отправка данных клиенту, а данные обновляются не часто, думаю, ajax будет легче. Вот в каких-нибудь онлайн играх web-сокет более приемлемый. Вот так я сам себе ответил на вопрос. Нахожусь в ожидании критики :)
Вы в любом случае отправляете запрос на сервер. Да и флаг ifModified вроде как никак не поможет если кеширование не настроено на уровне nginx-а. Да и это позволит вам просто обмениваться только заголовками. Да, этот метод работает и он прост в реализации, но он не оптимален. Хотя и у автора статьи вышло так себе.
p.s. Если бы web sockets поддерживали udp, было бы вообще круто для игрушек.
p.s. Если бы web sockets поддерживали udp, было бы вообще круто для игрушек.
Да, проще будет держать 10 000 подключений. Правда лучше для этого использовать node.js, который уже имеет встроенную обертку с мультиплексированием соединений и не нужно дополнительно писать алгоритмы оптимизирующие работу сервера. Профит тут такой:
10К соединений одновременных особо не грузят систему, просто у вас будет 10К дескрипторов, слежением за состояниями которых будет заниматься операционная система (при использовании select/epoll). В этом случае вам нужно отправлять данные только если это нужно. Что-то поменялось — шлете данные клиенту. Ничего не поменялось — ничего и не делаем.
А так вы предлагаете поддерживать порядка 1000 запросов в секунду и + порядка 1000 запросов к файловой системе в секунду. Проще уже взять и написать оптимизированный сервер под этим задачи. Благо сейчас это не так сложно.
10К соединений одновременных особо не грузят систему, просто у вас будет 10К дескрипторов, слежением за состояниями которых будет заниматься операционная система (при использовании select/epoll). В этом случае вам нужно отправлять данные только если это нужно. Что-то поменялось — шлете данные клиенту. Ничего не поменялось — ничего и не делаем.
А так вы предлагаете поддерживать порядка 1000 запросов в секунду и + порядка 1000 запросов к файловой системе в секунду. Проще уже взять и написать оптимизированный сервер под этим задачи. Благо сейчас это не так сложно.
Кстати, порт 8080 открыт не у 100% клиентов.
Клиент подключается к порту 8080, так что он должен быть открыт на сервере но никак не на клиенте.
Я думаю тут есть другая проблема: то, что WebSocket до сих пор в разработке и имеет туманное будущее.
Извините, я только не понял, как приходит к клиенту сообщение с типом «goal»? В коде нашел только тип «init».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание виджета «Счет Live» использую PHP Web Sockets