Периодические вызовы Ajax POST по сравнению с COMET / Websocket Push - PullRequest
3 голосов
/ 16 сентября 2011

На таком сайте, как Trello.com, я заметил в консоли Firebug, что он часто и периодически делает POST-вызовы Ajax на свой сервер, чтобы получать новые данные из базы данных и обновлять dom по мере появления чего-то нового.

С другой стороны, что-то вроде уведомлений Facebook, по-видимому, реализует механизм push COMET.

В чем преимущество и недостаток каждого подхода и, в частности, мой вопрос заключается в том, почему Trello.com использует «тягу»механизм, как я всегда думал, используя такой подход (тем более, что он пингует свой сервер так часто), поскольку кажется, что это не масштабируемое решение - когда все больше и больше пользователей регистрируются, чтобы использовать его сервисы?

1 Ответ

5 голосов
/ 11 апреля 2012

Короткий ответ на ваш вопрос

Ваш инстинкт кишки верен.Длинный опрос (он же комета) будет более эффективным, чем прямой опрос.И когда это возможно, веб-сокеты будут более эффективными, чем длительный опрос.Поэтому, почему некоторые компании используют «опрашивающий опрос», довольно просто: они устарели и должны уделить некоторое время обновлению своей кодовой базы!

Сравнение опроса, длинного опроса (кометы) и WebSockets

При традиционном опросе вы будете делать один и тот же запрос несколько раз, часто анализируя ответ как JSON, или помещая результаты в контейнер DOM в качестве содержимого.Частота этого опроса никак не связана с частотой обновления данных.Например, вы можете выбрать опрос каждые 3 секунды для новых данных, но, возможно, данные остаются неизменными в течение 30 секунд за один раз?В этом случае вы тратите впустую HTTP-запросы, пропускную способность и ресурсы сервера для обработки многих совершенно бесполезных HTTP-запросов (9 повторений одних и тех же данных, прежде чем что-либо действительно изменилось).

При длительном опросе (он же комета),Мы значительно сокращаем отходы.Когда ваш запрос на обновленные данные отправляется, сервер принимает запрос, но не отвечает, если нет новых изменений, вместо этого он удерживает запрос открытым в течение 10, 20, 30 или 60 секунд или до тех пор, пока не будут готовы некоторые новые данные.и это может ответить.В конце концов, запрос будет либо истек, либо сервер ответит обновлением.Идея заключается в том, что вы не будете повторять одни и те же данные так часто, как в 3-секундном опросе выше, но вы по-прежнему получаете очень быстрое уведомление о новых данных, поскольку, скорее всего, уже есть открытый запрос, ожидающий ответа сервера..

Вы заметите, что длительный опрос значительно уменьшил отходы, но все же есть шанс для некоторых отходов.30-60 секунд - это обычный период ожидания для длительного опроса, так как многие маршрутизаторы и шлюзы в любом случае отключат висящие соединения после этого времени.Так что, если ваши данные на самом деле меняются каждые 15 минут?Опрос каждые 3 секунды будет ужасно неэффективным , но длительный опрос с тайм-аутами в 60 секунд все равно будет иметь некоторые бесполезные поездки на сервер.

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

Проверка реальности

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

Существуют и другие преимущества наличия абстрактного коммуникационного уровня.Например, что, если у вас на странице 3 элемента управления сеткой, каждый из которых выполняет опрос каждые 3 секунды, видите, в каком беспорядке это будет?Теперь прокрутка вашей собственной реализации длинного опроса может немного убрать эту проблему, но было бы еще круче, если бы вы объединили обновления для всех этих трех таблиц в один запрос длинного опроса.Это снова сократит отходы.Если у вас небольшой проект, вы снова можете свернуть свой собственный, но есть стандартный Bayeux Protocol , которому следуют многие реализации push-серверов.Протокол Bayeux автоматически объединяет сообщения для доставки, а затем разделяет сообщения по «каналу» (произвольная строка в виде пути, которую вы, как разработчик, используете для направления ваших сообщений).Клиенты могут прослушивать каналы, и вы можете публиковать данные по каналам, сообщения будут поступать всем клиентам, прослушивающим каналы, на которые вы опубликовали.

Количество доступных наборов push-инструментов серверного сервера растетдовольно быстро в наши дни, так как технология Push становится следующей большой вещью.Вероятно, существует 20 или более рабочих реализаций сервера push.Сделайте свой собственный поиск для "реализации кометы {Ваша любимая платформа}", так как я буду уверен, что она будет меняться каждые несколько месяцев (и ранее она была рассмотрена в stackoverflow).

...