Назад | Перейти на главную страницу

lighttpd + PHP-fcgi медленный ответ

У нас есть проблема с lighttpd в качестве веб-сервера с php5 в качестве бэкэнда через fast-cgi. Иногда ответ сервера занимает более 5 секунд (до 20 секунд) при запросе простого файла, который вызывает phpinfo();. Журнал сервера не показывает ошибок, а ответ HTTP - 200.

Когда я запрашиваю статический html-файл без какого-либо содержимого PHP, проблем нет, и все запросы обрабатываются быстро.

Это конфигурация lighttpd-fcgi:

fastcgi.debug = 1
fastcgi.server += ( ".php" =>
    ((
        "bin-path" => "/usr/bin/php-cgi",
        "socket" => "/tmp/php.socket",
        "max-procs" => 7,
        "bin-environment" => (
            "PHP_FCGI_CHILDREN" => "5",
            "PHP_FCGI_MAX_REQUESTS" => "5000"
        )
    ))
)

Сервер работает под управлением Debian 7 64 бит.

Каждый рабочий процесс php может обрабатывать только один запрос за раз; каждая «процедура» (в вашем случае 7) обычно имеет главный процесс (который не обрабатывает запросы) и PHP_FCGI_CHILDREN (в вашем случае 5) рабочий процесс, что составляет всего 35 рабочих процессов.

lighttpd выделяет отдельный сокет для каждого «процесса», и каждый сокет имеет свою собственную очередь запросов. Поэтому, если обработка вашего запроса занимает много времени, скорее всего, у выбранного бэкэнда есть длинная очередь запросов для обработки.

Так что просто сделайте простую математику: если на обработку одного запроса у php уходит около 2 секунд, ваша установка может обработать #workercount / #timeperrequest = 17.5 запросов / сек.

Чтобы увеличить количество запросов в секунду, у вас есть два варианта:

запустите больше рабочих процессов php (и убедитесь, что у вас достаточно памяти / процессора для их запуска, смотрите top и другие инструменты)
улучшить время ответа на отдельные запросы (обратите внимание на медленные запросы SQL, HTTP-запросы к внутренним службам и т. д.); снова проверьте наличие узких мест в памяти и ЦП с помощью top - если ваш сервер начнет менять местами, все будет очень медленно.

PS: не вставляйте розетки в /tmp; положить их в (/var)/run/lighttpd/ вместо этого и убедитесь, что только ваш пользователь lighttpd (www-data) имеет доступ, см. CVE-2013-1427

Убедитесь, что у вас нет потерянных обработчиков fcgi, проще всего остановить lighttpd, а затем `ps auX 'и найти php-cgi. Убейте их, если таковые существуют, затем снова включите свет.

Настройте обработчик состояния сервера в своей легкой конфигурации. Это позволит вам обновить страницу и увидеть все обрабатываемые в настоящее время соединения и их состояние. http://redmine.lighttpd.net/projects/1/wiki/Docs_ModStatus

Проверьте, что лайт действительно может писать в свой журнал ошибок. При остановке и перезапуске лайт, он должен оставить журнал в error.log. Таким образом, если все ваши обработчики fcgi связаны и lighty должен задержать запрос, он это зарегистрирует.

Я бы не рекомендовал max-procs => 7, если у вас нет для этого очень веской причины. Попробуйте снизить max-procs до 1 и значительно повысить FCGI_CHILDREN. Мой сервер с высоким трафиком настроен на использование max-procs 1 и FCGI_CHILDREN 120. Я понимаю, что это противоречит wiki lighttpd, однако это редактируется пользователями, тогда как мое предложение основано на эмпирических доказательствах, а также на рекомендациях непосредственно от команды lighty.

Также следует иметь в виду, что для каждый обработать. Таким образом, уменьшив его до 1, все сценарии используют один и тот же кеш-код операции, что означает меньше времени, затрачиваемого на компиляцию и сокращение 7 разных кешей.