#apache #comet #long-polling #reverse-ajax #php
#apache #comet #длительный опрос #обратный-ajax #php
Вопрос:
Я работаю над веб-сайтом, который отображает некоторые данные из базы данных, которые часто меняются (статус очереди и чат-переписка). Моя текущая настройка — Apache / PHP / MySQL. Естественно, я хотел бы избежать опроса сервера каждые x секунд, поскольку это плохо масштабируется. Я хотел бы выполнить обратный длинный опрос ajax, однако я читал, что Apache плохо работает с этим, поскольку у него быстро заканчиваются рабочие потоки. Существует множество других веб-серверов, которые решают эту проблему: nginx, tornado и т.д. Однако моя проблема в том, что PHP — единственный язык сценариев на стороне сервера, который я знаю. Также я уже написал несколько PHP-скриптов, поэтому хотел бы сохранить их, если смогу. Я согласен с переключением сервера, пока я все еще могу использовать PHP.
Но после проведения дополнительных исследований я прочитал, что люди говорят, что PHP (PHP-FPM?) также создает процесс для каждого выполняемого запроса, что означает, что если у меня есть сотни / тысячи открытых подключений, будут сотни / тысячи процессов, что также будет проблемой.
Могу ли я сделать вывод, что нет хороших масштабируемых способов создания веб-сайтов с длинным опросом с использованием PHP? Должен ли я отказаться от PHP и изучить другой серверный язык сценариев? На данный момент я могу продолжить разработку длинного опроса, используя мою текущую настройку (Apache / PHP), но я не хочу, чтобы выбор языка сценариев накладывал какие-либо ограничения на масштабируемость моей системы при развертывании. Итак, что мне делать? Я не очень разбираюсь в веб-программировании, поэтому, если какие-нибудь гуру могут дать мне несколько советов, я был бы признателен! Спасибо!
Комментарии:
1. Сам этого не делал, но можно ли использовать js-сокеты? возможно, используя node.js тоже. Встроенная поддержка websockets в браузерах мне нравится, но я предполагаю, что плагин jquery справляется с этим?
2. На самом деле я не рассматриваю websocket, поскольку он поддерживается не во всех основных браузерах. Я просмотрел node.js на самом деле, но из того, что я слышал, это все еще относительно новый, поэтому поддержка фреймворка более ограничена. В настоящее время я рассматриваю Django, что означает, что я должен освоить python. Я слышал много хорошего о фреймворке, но я все равно предпочел бы остаться с php, если есть способ обойти падение производительности.
3. я бы определенно пересмотрел node.js — простой ajax-запрос к порту сервера node.js запуск на может быть просто трюком.
Ответ №1:
PHP, выполняемый в режиме php-fpm, по-прежнему будет иметь ограничения, особенно если ваш код потребляет много памяти. Вы не сможете запускать тысячи параллельных процессов без некоторой доступной памяти. Но обычно он выполняется быстрее, чем mod_php, и, по крайней мере, HTTP-запросы, которые не требуют PHP, обрабатываются веб-сервером, и если этот веб-сервер nginx, вы получите намного больше HTTP-запросов, доступных параллельно.
С php-fpm у вас также будет очередь ожидающих запросов, что может быть полезно в случае временного большого трафика, поскольку, по крайней мере, запросы ставятся в очередь, а не отклоняются.
Теперь операции длительного опроса в порядке с nginx (или другими, это пример), но не с PHP. PHP не создан для того, чтобы быть долго работающим сервером, каждый запрос — это новый процесс, это действительно неправильный выбор для сохранения работоспособности. Но «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 минуту после загрузки страницы. Поскольку пользователь все еще читает ту же страницу (или пьет кофе, разговаривает с другом, собирается в отпуск, не выключая компьютер, и т.д.), мы можем все больше и больше откладывать следующие проверки. Это способ предположить, что пользователь на самом деле не активен. Обратите внимание, что вы могли бы обнаружить активность пользователя другими способами и изменить перепланирование.
Ответ №2:
PHP не подходит для длительного опроса, Comet и технологий обратного ajax. Вы должны использовать Node.js
Комментарии:
1. пожалуйста, приведите несколько причин вместо ответа в одной строке.