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

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

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

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

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

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

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

• Предоставьте легкую конечную точку для ваших клиентов, у которой есть некоторый контекст сеанса чата, новое ожидающее сообщение, количество сообщений и т. Д. Клиент может ответить на это путем немедленного обновления, если нет новых сообщений. Эта конечная точка может предоставить простой объект json через HTTP-запрос. Вам гарантировано, что это сообщение статуса будет фиксированным, и если ответ статуса не изменится, вы можете его разложить. См. Следующее сообщение.

• Простой распад в вашем опросе javascript, если клиент получает один и тот же ответ от сервера несколько раз подряд, вы можете увеличить опрос на определенное время, в настоящее время вы сказали, что это была каждая секунда. Если вы это сделаете, вы увеличите количество до 2,4,6,8,10 секунд. Как только отклик от сервера изменится, вы сбросите разложение.

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

• Используйте кеш PHP-кода, например APC.

• Установите низкий тайм-аут для всех запросов, вы не хотите, чтобы какие-либо запросы зависали на вашем сервере.

• Оптимизируйте свой PHP-код, сделайте его быстрым и быстрым.

• Запустите некоторые тесты нагрузки, чтобы узнать, какие у вас ограничения.

• Частота производительности, чтобы убедиться, что ваши приложения становятся быстрее.

• Проверяйте журналы apache для указания признаков общего состояния приложения и времени ответа.

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

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

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