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

• Короткий опрос (он же таймер на основе AJAX):

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

• Длинный опрос (он же Comet на основе XHR)

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

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

Оба являются 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-> Yes. Have some lad.
00:00:03 C-> Is the other cake ready? ..

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

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

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

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

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

Websocket

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

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

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

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

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

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

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

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