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

Ответ 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.