ajax — должен ли сервер-отправляющий PHP-скрипт опрашивать?

У меня есть веб-приложение, управляемое в основном javascript / ajax, что-то вроде того, как работают документы Google; все люди, просматривающие страницу, будут видеть одну и ту же информацию в реальном времени. Это не важно, что информация на самом деле в режиме реального времени, секунда или около того в порядке.

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

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

1

Решение

В PHP опрос БД является типичным способом сделать это. Вы также можете использовать сокеты TCP / IP для подключения к какому-либо серверу приложений, который находится перед вашей базой данных и знает обо всех авторах и всех потребителях. То есть когда поступает запись, она передает ее всем потребителям и записывает в БД. Потребителями в этих примерах являются скрипты PHP (по одному на клиента SSE).

Если вы используете WebSockets, то вам нужна точно такая же архитектура, потому что PHP однопоточный: каждое соединение SSE является независимым процессом PHP.

Если вы переключитесь на использование, скажем, node.js, то этот сервер приложений может быть встроенным. (Опять же, это будет работать одинаково, будь то SSE или WebSockets.)

Но, Вы упоминаете, что собираетесь использовать виртуальный хостинг. SSE (и WebSockets, и технологии комет) держат открытый сокет, что мешает экономике общего хостинга. Таким образом, ваши розетки могут быть закрыты регулярно. Мой совет — придерживаться опроса ajax (и, следовательно, DB) каждые 5 секунд вместо SSE, пока ваше приложение не будет стоить достаточно, чтобы $ 10-100 / month для реального хоста не были проблемой. Затем рассмотрите возможность использования SSE для оптимизации задержки.

Постскриптум Решение между SSE и WebSockets полностью зависит от частоты записи. Мой совет, если ваши клиенты записывать Данные, в среднем, раз в секунду или чаще, веб-сокеты лучше, потому что это держит канал записи открытым. Если каждые 5+ секунд веб-сокеты не приносят много, по сравнению с использованием поста Ajax каждый раз, когда у вас есть данные для записи. С бэкэндом SSE легче работать, чем с бэкэндом WebSockets. (Пишет каждые 1-5 секунд — это серая область.)

2

Другие решения

Я бы порекомендовал вместо того, чтобы опрашивать базу данных на предмет изменений, вы будете знать, когда произойдет изменение базы данных, потому что ваше приложение будет вносить эти изменения. Я бы использовал веб-сокеты (https://developer.mozilla.org/en-US/docs/WebSockets) и просто отправьте обновление всем активным клиентам, когда какой-либо участник внесет изменение.

Вот разница между событиями отправки сервера и веб-сокетами. (В вашем случае веб-сокеты — это то, что нужно)

Websockets и SSE (Server Sent Events) способны передавать данные в браузеры, однако они не являются конкурирующими технологиями.

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

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

На практике, поскольку все, что можно сделать с помощью SSE, можно также сделать с помощью Websockets, Websockets привлекает гораздо больше внимания и любви, и многие другие браузеры поддерживают Websockets, чем SSE.

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

0

По вопросам рекламы [email protected]