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

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

оба являются 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 (или любой другой асинхронный подход - например, C++ 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? 

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

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

Websocket

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

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

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

краткий опрос - ну, не ^^.

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

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

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

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