Отправленные сервером события против опроса - PullRequest
Новая
       24

Отправленные сервером события против опроса

54 голосов
/ 22 февраля 2012

Есть ли большая разница (с точки зрения производительности, доступности реализации браузера, загрузки сервера и т. Д.) Между HTML5 SSE и прямым опросом Ajax? Со стороны сервера кажется, что EventSource просто нажимает на указанную страницу каждые ~ 3 секунды или около того (хотя я понимаю, что время гибкое).

Конечно, установить на стороне клиента проще, чем настроить таймер и иметь его $.get так часто, но есть ли что-нибудь еще? Он посылает меньше заголовков или делает что-то другое, что мне не хватает?

Ответы [ 2 ]

73 голосов
/ 03 марта 2012

Опрос Ajax добавляет много HTTP-издержек, поскольку он постоянно устанавливает и разрывает HTTP-соединения. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Отправленные сервером события открывают одно долгоживущее HTTP-соединение. Затем сервер однонаправленно отправляет данные, когда он у них есть, клиенту нет необходимости запрашивать их или делать что-либо, кроме ожидания сообщений.

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

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

Если вы делаете что-то, что требует только односторонней связи, я бы определенно выбрал отправленные сервером события. Как вы упомянули, отправляемые сервером события, как правило, проще и понятнее реализовать на стороне клиента. Вам просто нужно настроить прослушиватели для сообщений и событий, а браузер позаботится о низкоуровневых вещах, таких как переподключение при отключении и т. Д. На стороне сервера это также довольно легко реализовать, так как он просто использует простой текст. Если вы отправляете объекты в кодировке JSON, вы можете легко превратить их в объекты JavaScript на клиенте с помощью JSON.parse().

Если вы используете PHP на сервере, вы можете использовать json_encode(), чтобы превратить строки, числа, массивы и объекты в правильно закодированный JSON. Другие внутренние языки также могут предоставлять аналогичные функции.

3 голосов
/ 15 января 2017

Я бы только добавил более высокую перспективу к тому, что было сказано, и это то, что SSE является моделью публикации-подписки, а не постоянным опросом в случае AJAX.

Как правило, оба способа (опрос и публикация-подписаться) пытаются решить проблему, как поддерживать на клиенте актуальное состояние.

1) Модель опроса

Это просто.Клиент (браузер) сначала получает начальное состояние (страницу) и для его обновления ему необходимо периодически запрашивать состояние (страницу или его часть) и обрабатывать результат в текущем состоянии (обновить всю страницу или сделать ее интеллигентночасть в случае AJAX).

Естественно, один недостаток состоит в том, что, если ничего не происходит с состоянием сервера, ресурсы (ЦП, сеть, ...) используются излишне.Другая причина в том, что даже если состояние меняется, клиенты получают его только в следующий период опроса, а не как можно скорее.Часто нужно оценить хороший компромисс по времени между этими двумя вещами.

Другим примером опроса является ожидание в потоке.

2) Модель публикации-подписки

Этоработает следующим образом:

  • (клиент сначала запрашивает и показывает некоторое начальное состояние)
  • клиент подписывается на сервер (отправляет один запрос, возможно, с некоторым контекстом, например источником события)
  • сервер помечает ссылку на клиента на некоторый его клиентский репозиторий
  • в случае обновления состояния сервер отправляет уведомление клиенту на основании ссылки на клиент, который он держит;то есть это не ответ на запрос, а сообщение, инициированное сервером
  • хорошие клиенты отписываются, когда их больше не интересуют уведомления

Это SSE или в потокеожидаемое событие, как еще один пример.Как уже говорилось, естественным недостатком является то, что сервер должен знать обо всех своих подписанных клиентах, что, в зависимости от реализации, может быть проблемой.

...