Масштабирование приложения чата - короткий опрос и длительный опрос (AJAX, PHP)

Я запускаю веб-сайт, на котором пользователи могут общаться друг с другом через браузер (подумайте в чате Facebook). Каков наилучший способ взаимодействия с живым взаимодействием? (Прямо сейчас у меня есть опрос каждые 30 секунд, чтобы обновлять онлайн-пользователей и новые входящие сообщения, а другой опрос, проходящий по страницам чата каждую секунду, для получения новых сообщений.)

Вещи, которые я рассмотрел:

HTML5 Web Sockets: не использовал это, потому что он не работает во всех браузерах (только хром).
Flash Sockets: не использовал это, потому что я хотел в конечном итоге поддерживать мобильную сеть.

Прямо сейчас, я использую короткий опрос, потому что я не знаю, как будет масштабироваться длинный опрос AJAX. Сейчас я запускаю сервер VPS из servint (работает apache). Должен ли я использовать длительный опрос или короткий опрос? Мне не нужны абсолютно мгновенные ответы (просто "достаточно хорошо" для чат-приложения). Является ли короткий опрос чаще всего несколькими тысячами пользователей, которые собираются убить мой сервер? Как мне масштабировать, пожалуйста, помогите!

Ответ 1

Несколько примечаний:

Опрос каждую секунду является излишним. Приложение будет по-прежнему чувствовать себя очень отзывчивым с несколькими секундами задержки между проверками.
Чтобы сохранить ваши ответы на трафик и скорость обмена сообщениями, рассмотрите возможность использования кеша в памяти для хранения недостигнутых сообщений. Вы по-прежнему сохраняете сообщения в db, кеш в памяти просто будет использоваться для запросов для новых сообщений, чтобы избежать запросов к db каждые x секунд каждым пользователем.
Тайм-аут чата пользователя после x секунд бездействия, чтобы остановить опрос на вашем сервере. Это гарантирует, что кто-то, покинув окно, не продолжит генерировать трафик. Предложите простой "Еще есть? Продолжайте общаться". ссылку на сеансы с таймаутом и предупредить пользователя перед таймаутом, чтобы они могли продлить время ожидания.
Я бы предложил начать опрос, а не комет/длинные опросы/сокеты. Опрос прост в построении и поддержке, и, скорее всего, он будет масштабироваться только в краткосрочной перспективе. Если вы получаете большой трафик, вы можете бросить оборудование и балансировщик нагрузки на проблему масштабирования. Вся сеть основана на опросе - опрос, безусловно, масштабы. Там, где сложность альтернатив, таких как комета/длинный опрос/и т.д., Имеет смысл, но вам нужно много трафика до того, как будет оправдано дополнительное время/сложность разработки.

Ответ 2

Это то, что каждый раз делал когда-то до введения комет и узлов.

Проблема в том, что PHP-запросы на Apache очень дороги. Если ваше чат-приложение проверяет сообщения каждый раз, вы окажетесь в ситуации, когда Apache не располагает достаточными ресурсами для ответа на запросы. Другая область, которая, я думаю, нуждается в улучшении, заключается в улучшении контекста вашего приложения чата.

Почему он обновляется каждую секунду, если не получать новые сообщения? Что делать, если сообщений нет?

Некоторые методы, которые вы можете использовать;

Обеспечьте легкую конечную точку для своих клиентов, которая имеет некоторый контекст сеанса чата, представляет собой новое ожидающее сообщение, количество сообщений и т.д. Клиент может ответить на это путем обновления немедленно или нет, если нет новые сообщения. Эта конечная точка может предоставить простой объект json через HTTP-запрос. Вам гарантировано, что это сообщение статуса будет фиксированным, и если ответ статуса не изменится, вы можете его разложить. См. Следующее сообщение.
Простой распад в вашем опросе javascript, если клиент получает один и тот же ответ от сервера несколько раз подряд, вы можете увеличить опрос на установленное время, в настоящее время вы сказали, что это была каждая секунда. Если вы это сделаете, вы увеличите количество до 2,4,6,8,10 секунд. Как только ответ с сервера изменит ваш reset распад.

Некоторые оптимизации для рассмотрения;

Используйте кеш PHP-кода, например APC.
Установите низкий тайм-аут для всех запросов, вы не хотите, чтобы какие-либо запросы зависали на вашем сервере.
Оптимизируйте свой PHP-код, сделайте его быстрым и быстрым.
Запустите некоторые тесты нагрузки, чтобы узнать, какие у вас ограничения.
Частота производительности, чтобы убедиться, что ваши приложения становятся быстрее.
Проверяйте журналы apache для указания признаков общего состояния приложения и времени отклика.

Когда масштабирование становится необходимым, добавьте новый сервер и используйте балансировщик нагрузки для распространения запросов. Я использовал Varnish и HAProxy с большим успехом, их настройка тоже не сложна.

Ответ 3

Если бы я был вами, я бы выбрал библиотеку, которая использует html5 веб-сокеты, но снова падает на сокеты Flash, если html5 недоступен, браузер, который попадает в трещины, должен быть минутным.

Также вы должны либо отказаться от php, либо добавить его с помощью потокового сервера сокетов, написанного либо в python, либо ruby с помощью em-websocket.