Уведомление клиента, следует ли использовать AJAX Push или опрос?

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

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

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

Спасибо за вашу помощь.

EDIT: Я рассмотрел простой AJAX Push и реализовал простую демонстрацию на основе этого article Майка Первиса. Нагрузка клиента довольно низка примерно на 5 тыс. Для начальной версии и ожидается, что она останется в течение довольно длительного времени.

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

Ответ 1

Поскольку использование push требует открытого HTTP-соединения между вашим сервером и каждым клиентом, я бы пошел на опрос, а не только на то, что он будет потреблять много ресурсов сервера, но это также будет значительно более сложным для реализации с учетом матового b.

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

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

Ответ 2

Я удивлен, что никто здесь не упомянул длинный опрос. Длительный опрос означает сохранение открытого соединения в течение более длительного периода (например, 30-60 секунд), и после его закрытия, повторного открытия его снова и просто прослушивания гнезда/соединения для ответов. Это приводит к меньшему количеству соединений (но более длинных) и означает, что ответы почти мгновенно (некоторым, возможно, придется ждать нового опроса). Я хотел бы добавить, что в сочетании с такими технологиями, как NodeJS, это приводит к очень эффективному и ресурсосберегающему решению, которое на 100% совместимо с браузером во всех основных браузерах и версиях и не требует каких-либо дополнительных технологий, таких как Comet или Вспышка.

Я понимаю, что это старый вопрос, но подумал, что может быть полезно предоставить эту информацию:)

Ответ 3

Определенно используйте push гораздо круче. Если вам просто нужны простые уведомления, я бы использовал что-то вроде StreamHub Push Server, чтобы сделать тяжелую работу для вас. Разработка собственной функциональности Ajax Push - чрезвычайно сложная и скалистая дорога - вам нужно заставить ее работать во всех браузерах, а затем обрабатывать брандмауэры и прокси, убивая связи keep-alive и т.д. Зачем изобретать колесо. Кроме того, он имеет такой же низкий размер менее 10 КБ, поэтому он должен соответствовать, если это приоритет для вас.

Ответ 4

Оба имеют разные требования и адресуют разные сценарии.

Если вам нужны обновления в реальном времени, например, в онлайн-чате, нажмите "обязательный".

Но если период обновления, как и в вашем случае (5 минут), то пул является подходящим решением. Push, в этом случае, потребует много ресурсов как от клиента, так и от сервера.

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

Ответ 5

Я бы выполнил опрос только потому, что он звучит проще писать, а его простота очень ценна.

Ответ 6

Не уверен, что вы взглянули на некоторые из реализаций COMET (это то, что вы подразумеваете под AJAX push).

Если пользователь просматривает сайт, не будет ли это на самом деле запрашивать информацию с сервера о том, что это уведомление может копировать?

Ответ 7

Я сам не пробовал, но некоторые говорят COMET работает и проще, чем вы думаете. Там также подключен плагин Ruby on Rails, называемый Juggernaut, о котором я слышал. Опять же, я не использовал его, поэтому YMMV, но я понимаю, что он занимает гораздо меньше ресурсов по сравнению с опросом. Я верю (может кто-то подтвердить?), Что COMET - это как MacRumorsLive.com обеспечивает живое ведение блога WWDC Stevenotes.

Ответ 8

Невозможно сказать, будет ли опрос дороже, а затем нажимать, не зная, сколько у вас клиентов. Я бы рекомендовал опрос, потому что:

Похоже, вы хотите обновлять данные примерно раз в минуту. Если уведомления не могут достичь гораздо более высокой скорости, то нажатие означает, что вы поддерживаете HTTP-соединение открытым, но на нем мало активности.
Опрос построен поверх существующих HTTP-соглашений, поэтому любой сервер, который разговаривает с веб-браузерами, уже готов отвечать на обычные запросы Ajax. Решение на основе сокета Comet или Flash имеет разные требования; вам понадобится что-то вроде cometd на стороне сервера и клиентской библиотеки, которая будет нажимать на серверную сторону.

Итак, если вам нужно что-то сверхмощное для управления потоком данных и избытком клиентов, я бы порекомендовал Comet. Но, похоже, это не так.

Ответ 9

Теперь существует служба http://pusherapp.com, которая пытается решить эту проблему раз и навсегда, мгновенно. Возможно, стоит проверить. (отказ от ответственности: я никоим образом не связан с ними).