Является ли php масштабируемым с длинным опросом обратного ajax? - PullRequest
5 голосов
/ 11 ноября 2011

Я работаю над веб-сайтом, который отображает некоторые данные из БД, которые часто меняются (состояние очереди и разговор в чате).Моя текущая настройка - Apache / PHP / MySQL.Естественно, я хотел бы избегать опроса сервера каждые х секунд, так как это плохо масштабируется.Я хотел бы сделать обратный длинный опрос ajax, однако я прочитал, что Apache не работает с этим, так как он быстро исчерпывает рабочие потоки.Существует много других веб-серверов, которые решают эту проблему: nginx, tornado и т. Д. Однако моя проблема в том, что PHP - это единственный серверный язык сценариев, который я знаю.Также я уже написал несколько сценариев PHP, поэтому я хотел бы сохранить их, если смогу.Я в порядке с переключением сервера, пока я все еще могу использовать PHP.

Но после некоторых исследований я прочитал, что люди говорят, что PHP (PHP-FPM?) Также создает процесс для каждого сделанного запроса.Это означает, что если у меня будут сотни / тысячи открытых соединений, будут сотни / тысячи процессов, которые также будут проблемой.

Могу ли я заключить, что не существует хороших масштабируемых способов сделать длинные сайты с использованием опросовPHP?Должен ли я отказаться от PHP и изучить другой язык сценариев сервера?Сейчас я могу продолжить разработку длинных опросов, используя мою текущую настройку (Apache / PHP), но я не хочу, чтобы выбор языка сценариев накладывал какие-либо ограничения на масштабируемость моей системы при развертывании.И что же мне делать?Я не очень разбираюсь в веб-программировании, поэтому, если кто-нибудь из гуру сможет дать мне несколько советов, я буду признателен!Спасибо!

Ответы [ 2 ]

7 голосов
/ 19 февраля 2012

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

С php-fpm у вас также будет очередь ожидающих запросов, которая может быть полезна в случае временного большого трафика, так как по крайней мере запросы помещаются в очередь, а не отклоняются.

Теперь длинные операции опроса в порядке с nginx (или другими, это пример), но не с PHP. PHP не предназначен для длительного использования , каждый запрос - это новый процесс, это действительно неправильный выбор для KeepAlive. Но " Divide ut regnes " (разделяй и властвуй). Ваши длинные опросы могут выполняться рядом с вашим PHP-приложением, но без вашего PHP-приложения.

В качестве примера рассмотрим проект jappix , это проект PHP. Но вам нужно где-то установить сервер XMPP (например, ejabberd) и сервер BOSH с nginx в качестве прокси на порту 80 к этому серверу BOSH (так что у вас есть протокол чата xmpp на порту 80, через nginx и ejabberd, и ничего на сторона PHP для этого). Тогда проблема заключается в том, чтобы подключить аутентификацию, идентификацию и т. Д. Вашего приложения, и это нужно будет сделать, расширив конфигурацию сервера XMPP (чтобы он использовал тот же сервер LDAP, что и ваше PHP-приложение, например).

Вторая проблема с длительным опросом - это состояние очереди. Вы можете найти некоторые расширения XMPP для этого, может быть. Или вы можете выполнять регулярные запросы Ajax в очереди. Одним из полезных приемов, позволяющих избежать большого количества запросов ajax в вашем приложении PHP, является перепланирование следующей проверки ajax обратного вызова ajax проверки, основанной на числах Фибоначчи (это пример). Поэтому первый раз следующий вызов ajax будет запланирован через 1 минуту, в следующий раз через 2 минуты, затем через 3, 5, 8, 13, 21, 34, 55, 89, 144 и т. Д. Идея заключается в том, что, возможно, важно проверить новых сообщений 1 минута после загрузки страницы. Поскольку пользователь все еще читает ту же страницу (или пьет кофе, разговаривает с другом, уходит в отпуск, не выключая компьютер и т. Д.), Мы можем все больше откладывать следующие проверки. Это способ предположить, что пользователь не очень активен. Обратите внимание, что вы можете обнаружить активность пользователя другими способами и изменить расписание.

0 голосов
/ 20 мая 2013

PHP не подходит для длинных опросов, технологий Comet и reverse ajax. Вы должны использовать Node.js

...