Эффективность / накладные расходы EventSource против опроса AJAX?

Question

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

Я пытаюсь сделать это как можно проще для кодирования. PHP на бэкэнде без каких-либо фантазий.

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

Затем я посмотрел на другие HTML5 способы сделать это и нашел EventSource - это кажется правильным в теории, но мне интересно, что под прикрытием это все равно опрашивается ajax.

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

Полагаю, я могу использовать длинный опрос - это лучший подход?

Кроме того, как вы минимизируете запросы БД от всех клиентов, запрашивающих новые данные?

Answer 1

Я думаю, что короткий опрос - это самый простой код, но он может создать ненужную нагрузку на сервер.

Длинный опрос более эффективен, но у вас должен быть сервер, способный эффективно поддерживать множество соединений (то есть не Apache).

И да, EventSource - это просто прославленный длинный опрос, но с ним приятно работать.

Отвечая на ваш второй вопрос: лучший способ минимизировать количество запросов к БД - не делать запросов к БД. Положите вещи в memcached, например.

Answer 2

Серхио дал хороший ответ на вопрос EventSource.Он также заявляет, что Apache не будет масштабироваться для обработки множества одновременных / одновременных соединений.У PHP на Apache есть эта проблема - особенно если вы используете виртуальный хостинг.

Лучшее решение для PHP - это аутсорсинг веб-коммуникаций в реальном времени и распространение сообщений.Вы можете сделать это самостоятельно, используя самодостаточное веб-решение в реальном времени ...

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

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

• Когда пользователь присоединяется к комнате, он подписывается на chat-channel.Имя может быть специфичным для темы разговора, например chat-fishing (больше информации о каналах здесь )
• Когда пользователь отправляет сообщение чата, ваш сервер получит это сообщение (возможно, черезAJAX-запрос)
• Вы обновите свою базу данных этим новым сообщением
• Как только БД успешно обновится, вы можете затем распространить (передать) это сообщение каждому пользователю в той же комнате чата, вызвавСобытие new_message на канале chat-channel.Это выполняется с помощью API RESTful, размещенного в службе, с использованием библиотеки PHP (которая включает любую функциональность, такую ​​как аутентификация, требуемая для API RESTful).
• Сообщение получено подключенными клиентами.

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

Существует хорошее руководство по , как создать чатприложение, использующее PHP с Pusher на Nettuts + .

Хотя это решение / ответ очень ориентировано на Pusher, концепции (преимущества аутсорсинга, подписки, каналы и события) применимы ко всем размещенным в реальном времени службам , которые поддерживают push клиента в реальном времени.