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

Question

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

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

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

Сейчас я использую короткий опрос, потому что я не знаю, насколько масштабным будет длинный опрос AJAX.Я сейчас использую VPS сервер из сервинта (работает Apache).Должен ли я использовать длинный опрос или короткий опрос?Мне не нужно абсолютно немедленное время ответа (просто «достаточно хорошо» для приложения чата).Часто ли происходит короткий опрос, когда несколько сотен тысяч пользователей собираются убить мой сервер?Как мне масштабировать это, пожалуйста, помогите!

Answer 1

Несколько заметок:

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

Answer 2

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

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

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

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

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

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

Некоторые варианты оптимизации, которые следует учитывать;

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

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

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

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

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

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

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

Answer 3

Если бы я был на вашем месте, я бы выбрал библиотеку, которая использует веб-сокеты html5, но при этом не поддерживает флэш-сокеты, если html5 не доступен, браузер, который падает через трещину, должен быть минутным.следует либо отказаться от php, либо дополнить его многопоточным сервером сокетов, написанным либо на python, либо на ruby ​​с помощью em-websocket.