Короткие опросы и длительный опрос для веб-приложений в реальном времени?

Ответ 1

• Короткий опрос (a.k.a. AJAX основанный таймер):

  Плюсы: проще, а не потреблять сервер (если время между запросами длинное).
  Минусы: плохое, если вам нужно получить уведомление, КОГДА событие сервера происходит без задержки. Пример (ItsNat)

• Длительный опрос (a.k.a. Comet на основе XHR)

  Плюсы: вы получаете уведомление, КОГДА событие сервера происходит без задержки. Минусы: более сложные и более используемые серверные ресурсы. Пример (на основе ItsNat)

Ответ 2

Просто ради аргумента.

Оба являются HTTP-запросами (xhr), и по крайней мере частично неверно он использует больше ресурсов сервера (полностью зависит от технологии, объяснит позже).

Короткий опрос.

Лот запроса, который обрабатывается по мере их поступления на сервер. Создает много трафика (использует ресурсы, но освобождает их, как только отклик возвращается):

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yeah. Have some lad.
00:00:03 C-> Is the other cake ready? ..

Длительный опрос

Один запрос отправляется на сервер, и клиент ожидает ответа (его неразрешенный). В случае, если сервер с php/apache будет означать порожденный поток для обработки, резервные ресурсы, до его завершения. Таким образом, трафик меньше, но вы быстро едите ресурсы (или, скорее, блокируете ресурсы). Но если вы используете, например, Node (или любой другой асинхронный подход - например, С++ qt), вы можете потенциально свести к минимуму использование ресурсов (хранить объект ответа для HTTP-запроса и использовать его, когда работа будет готова)

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yeah.Hame some lad.
12:00 00:00:03 C-> Is the cake ready? 

Если вы сравните это с коротким опросом, вы увидите, что потенциально в коротком опросе вы использовали большую передачу, но в течение этих 3 секунд вы фактически занимаете 1,5 с времени обработки (значит, что-то может быть выполнено между вашими вызовами). В случае долгого опроса одни и те же ресурсы использовались все время. Теперь обычно php со всеми libs начинается с 4MB-памяти - тогда у вас есть каркас 4-20MB. Предположим, что у вас есть 1024 МБ оперативной памяти (бесплатно). Скажем, можно пессимистично предположить, что вы будете использовать 25 МБ за один php файл. Это означает, что вы можете получить только до 40 длинных протоколов подключения.

Именно в этом причина, по которой вы могли бы использовать потенциально намного больше с Node, поскольку Node не будет создавать свои экземпляры (если вы не хотите использовать работников и т.д.), поэтому с той же памятью вы, вероятно, можете легко добраться до 10k соединения висят. Вы получите всплеск в ЦП по мере их поступления, и когда они будут потенциально выпущены, но когда они простаивают, похоже, их нет (вы платите только за структуры памяти, которые вы сохранили бы в node/С++).

WebSocket

Теперь, если вы хотите отправить несколько вещей, всякий раз, когда они находятся в клиенте или вне его, перейдите к websockets (ws protocol). Первый вызов - это размер HTTP-запроса, но позже вы отправляете только сообщения, от клиента к серверу (новые вопросы) и от сервера к клиенту (ответы или нажатия - может даже транслировать для всех подключенных клиентов). Есть php websocekts libs, но опять же используйте другую технологию - Node или С++.

Некоторые библиотеки, такие как socket.io, имеют собственную иерархию, поэтому, когда websocket терпит неудачу, он возвращается к длинному или короткому опросу.

Когда использовать.

Короткий опрос - ну, никогда ^ ^.

Длинный опрос - возможно, когда вы обмениваетесь одним вызовом с сервером, а сервер выполняет некоторую работу в фоновом режиме. Также, когда вы больше не будете запрашивать сервер на той же странице. Также, когда вы не используете php в качестве слоя для обработки длинного опросного соединения (node/С++ может быть простым средним уровнем). Примечание. Длительный опрос может быть действительно полезным, но только тогда, когда вы это сделаете.

Websocket - вы потенциально сможете обменять более одного или двух вызовов на сервер, или что-то может произойти с сервера, которого вы не ожидали/не спрашивали, например, уведомления об электронной почте или что-то в этом роде. Вы должны планировать разные "комнаты", в зависимости от функциональности. Объявите характер javascript, основанный на событии;]

Ответ 3

Если вы хотите получить приложение реального времени на основе базы данных, вы можете использовать комбинацию ajax long poll и comet. Длительный опрос действительно хорош для вашей полосы пропускания, а также он действительно полезен для пользователя MB.Because, когда пользователь отправляет запрос, пользователь будет платить за него, как MB или какое-то интернет-соединение. Например, для Короткий опрос, когда вы делаете что-то вроде отправки запроса в секунду, использование интернет-пользователей будет больше, потому что каждый пользователь подключается за него (это означает, что пользователь не загружает Mb), но в длинном опросе пользователь будет платить только за новые сообщения.

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