lighttpd + PHP-fcgi замедляют ответ

У нас есть проблема относительно lighttpd как веб-сервер с php5 как бэкенд через быстро-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 бита.

1
задан 6 February 2015 в 12:31
2 ответа

Ստուգեք, որ որբ որևէ fcgi բեռնաթափող չունեք, ամենահեշտ ձևն է դադարեցնել lighttpd- ը, ապա `ps auX 'և փնտրեք php-cgi: Սպանեք նրանց, եթե գոյություն ունեն, ապա նորից սկսեք լուսավորվել:

Ձեր լուսավոր կազմաձևում կարգավորեք սերվերի կարգավիճակի կարգավար: Սա թույլ կտա ձեզ թարմացնել էջը և տեսնել բոլոր կապերը, որոնք այժմ վարվում են, և թե ինչ վիճակում են դրանք: http://redmine.lighttpd.net/projects/1/wiki/Docs_ModStatus

Check lighty- ն իրականում ի վիճակի է գրել իր սխալի տեղեկամատյանում: Lighty- ը կանգնեցնելիս և վերագործարկելիս այն պետք է թողնի մուտք `error.log: Այս եղանակով, եթե ձեր fcgi բեռնաթափողները բոլորը կապված լինեն, և թեթևակի պետք է ինչ-որ հարցումը կասեցնի, այն կգրանցի այն:

Ես խորհուրդ չեմ տա max-procs => 7, եթե դրա համար շատ լավ պատճառ չունեք: Փորձեք իջեցնել առավելագույն գումարները 1-ի և զգալիորեն բարձրացնել ձեր FCGI_CHILDREN- ը: Իմ բարձր երթևեկության սերվերը կազմաձևված է այնպես, որ օգտագործի max-procs 1 և FCGI_CHILDREN 120: Գիտակցում եմ, որ դա հակասում է lighttpd վիքիին, այնուամենայնիվ, այն խմբագրում են օգտվողները, մինչդեռ իմ առաջարկը հիմնված է էմպիրիկ ապացույցների և նաև ուղղակի լույսի թիմի խորհրդատվության վրա:

Մյուս բանը, որ պետք է հիշել, այն է, որ յուրաքանչյուր գործընթացի համար պահպանվում է առանձին օպկոդային քեշ: Այսպիսով, այն իջեցնելով 1-ի, բոլոր սցենարները օգտագործում են նույն կոդային պահոցը, ինչը նշանակում է, որ ավելի քիչ ժամանակ է ծախսվել 7 տարբեր պահոցների կազմման և էտման համար:

1
ответ дан 3 December 2019 в 21:00

Каждый рабочий процесс 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

1
ответ дан 3 December 2019 в 21:00

Теги

Похожие вопросы