Руководство по использованию nginx + PHP в режиме FastCGI

>Нет, клиенты на низкоскоростных линиях. Отфоркнутый апач висит и занимает память, пока не отдаст всё до последней капли. Или пока по таймауту не порвёт коннект. Поэтому в таких случаях используют reverse-proxy.

Что мешает повесить apache на loopback, а на внешний IP - акселератор?

>Бенчей apache vs nginx у меня нет

У меня на машине форум Apache2+mod_php сожрал практически все ресурсы (база в 600+ тыс постингов, 1.7Гб текста, 160 человек в онлайне). После перевода его на lighttpd+php/fastcgi жрёт относительно немного, хватает ресурсов и на сервер с MMORPG на той же машине :)

Хотя планирую перевод форума на свой движок с исползованием статики - вот тут lighttpd вообще рвёт Апач как тузик известное резиновое изделие :)

linux, ядра 2.6, сборка 1:1 с debian/rules (полный список параметров можно посмотреть на packages.debian.org) за исключением ключа под тредовость, нагрузка порядка сотни реквестов в секунду, проявляется в "залипании" чилдов (контент не отдает, коннект не рвет, висит и слот жрет).

> linux, ядра 2.6, сборка 1:1 с debian/rules (полный список параметров можно посмотреть на packages.debian.org) за исключением ключа под тредовость, нагрузка порядка сотни реквестов в секунду, проявляется в "залипании" чилдов (контент не отдает, коннект не рвет, висит и слот жрет).

Аднака... А со статическим контентом происходит/не происходит? Если происходит - на каких нагрузках?

IMO похоже на проблемы с трёдами в PHP либо на проблемы с сокетами в ядре. Мож экспериментальное что-то из них было?

Просто примерно два года назад стояла одна машинка и держала около 1кк уников в сутки (~200-250 cps в пике). Под FreeBSD, где apache тормознутее. Твикалась правда недели полторы, но в общем работала со старта, остальное - доводка до идеала.

>> При переполнении очереди nginx сбрасывает её и начинает обрабатывать соединения с помощью метода poll до тех пор,

>> пока ситуация не нормализуется.

> Отличная фича для продакшеновых серверов, вам так не кажется?

Да, хорошая, если вспомнить что фича возникла как workaround для ошибок с rtsig в ранних ядрах 2.6. Можете предложить лучше ?

> Беглый просмотр кода совсем не порадовал.. Шаманизм чистой воды мелькает..

> Не буду я его ставить :-) Ни с FastCGI ни без :-)

Наверное Вы и ядро linux не ставите, там шаманства поболе будет..

А статики на том сервере отродясь не было -- она mathopd'ом отстреливается с другой машины с nfs-mount'а. Так что не скажу, но тест ab'ой прошел.
С другой стороны -- дело может быть в thread safety тех библиотек для php, что там применялись (а их штук 10 было).

> А статики на том сервере отродясь не было -- она mathopd'ом отстреливается с другой машины с nfs-mount'а

Дело личное. Предпочитаю всё-таки reverse-proxy - масштабировать удобнее в случае необходимости.

> С другой стороны -- дело может быть в thread safety тех библиотек для php, что там применялись

Вполне возможно. Хотя и маловероятно - они не могут клинить apache ТАК. 
PHP - это ведь просто разновидность content-filter :-)

Я даж проверить решил на собственном десктопе.
[-- CUT --]
nblx# HEAD -uesSd 'http://localhost/index.php'
HEAD http://localhost/index.php
HEAD http://localhost/index.php --> 200 OK
Connection: close
Date: Wed, 31 May 2006 16:55:05 GMT
Server: Apache/2.2.2 (FreeBSD) PHP/5.1.4
Content-Type: text/html
Client-Date: Wed, 31 May 2006 16:55:05 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1
X-Powered-By: PHP/5.1.4

nblx# ab -q -c 150 -n 10000 http://localhost/index.php
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).....done


Server Software:        Apache/2.2.2
Server Hostname:        localhost
Server Port:            80

Document Path:          /index.php
Document Length:        29752 bytes

Concurrency Level:      150
Time taken for tests:   70.793784 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      299186376 bytes
HTML transferred:       297516376 bytes
Requests per second:    141.26 [#/sec] (mean)
Time per request:       1061.907 [ms] (mean)
Time per request:       7.079 [ms] (mean, across all concurrent requests)
Transfer rate:          4127.11 [Kbytes/sec] received
[-- CUT --]

Ничего из описанного не произошло как видите.. Медленно - но это же всё-таки десктоп :-)

А вообще - поднимите тему на форуме если интересно, ибо уже оффтопик.

Что лично меня не порадовало в nginx:
1. Для каждого location нужно прописывать root каталог. Если его не прописать, будет использоваться дефолтный (/usr/local/nginx/html)... Что представляется полным идиотизмом, особенно если на сервере не один виртуалхост. Намного логичнее было бы по дефолту использовать тот каталог, который прописывается рутовым для "location /" и меня его только если принудительно указан рут для конкретного location.
2. Какое-то офигительно непонятное шаманство с valid_referers. Смысл вот в чем:
нужно сделать, чтобы htmlины были доступны всем, а вот файлы заданных типов - только если реферрер указан правильным.
Делаю:

server {
listen 192.168.1.1:80;
server_name myphoto.myhost.ru;
# access_log /var/log/nginx.log main;
valid_referers example1.ru example2.ru [none blocked];
location / {
root /site/;
index index.html index.htm;
}
location ~ /\.ht {
root /site/;
deny all;
}
location ~* ^.+\.(php|php3|phtml|htm|html)$ {
root /site/;
fastcgi_pass localhost:10000;
include /usr/local/nginx/conf/fastcgi_params;
}
location ~* ^.+\.(ext1|ext2|ext3|ext4)$ {
root /site/;
if ($invalid_referer) {
return 403;
}
}
}

И в итоге нгинкс refused все-равно делает в том числе на htmlины... :-(

Понимаю, что глупо и необоснованно звучит, но ведь в том то и дело, что комп один и тот же - в частности памяти 1 гиг и ее хватало, проблема была именно в ресурсах процессора. В определенные моменты апач просто еле передвигался (запросов действительно было порядочно), но вот почему после установки связки нгинкс - пхп фаст-цги стало именно ОЩУТИМО меньше загрузка - я и сам бы хотел услышать ответ. (апач был 1.х). кстати вопрос знающим - никто не делал связки нгинкс - питон - фастцги? (можно и лайтхттп)

> никто не делал связки нгинкс - питон - фастцги? (можно и лайтхттп)

Я django так запускаю (под lighttpd). =) А вообще, для этого есть flup - http://www.saddi.com/software/flup/.

> (апач был 1.х)

Это значит - prefork. С положенным ему выжиранием памяти. Переход на 2.х mod_worker спасёт. 1G оперативной памяти для apache 1.x - это очень немного, если планируется серьёзная нагрузка. На вскидку - примерно 50-60 форкнувшихся индейских друзей. I.e. ~60 rps в пике, а дальше начинаем сильно тормозить. Обрезание лишних модулей в общем-то спасёт, но не сильно.

>> При переполнении очереди nginx сбрасывает её и начинает обрабатывать соединения с помощью метода poll до тех пор,
>> пока ситуация не нормализуется.

>Отличная фича для продакшеновых серверов, вам так не кажется?

Не вырывайте из контекста. Посмотрите при переполнении какой очереди чего это происходит.

Nginx - это сервер, написанный Игорем Сысоевым, работающим в компании Rambler. Именно на этом сервере работают веб-сервера Rambler. Или вам кажется, что это недостаточное испытание на прочность?

Что же до того, что "весь рунет завален сообщениями connection timeout от nginx", то дело тут не в nginx. Обычно nginx ставят перед Apache или каким-то ещё сервером, чтобы отдавать статику и т.п. Вот именно Apache и валится - не выдерживает нагрузки, о чём nginx и сообщает.

Хех... Как оказалось, это был правильный конфиг...

Проблема была в том, что php вылетал.
Для корректной работы, перед запуском php нужно прописать:

export PHP_FCGI_CHILDREN=10
export PHP_FCGI_MAX_REQUESTS=100000

У тебя в index.php что написано ? phpinfo() и всё :) ?
С mod_php в multithreaded окружении возникают грабли не с самим php, а с его различными extensions, коих наплодили уже миллион. В частности на сколько я помню, какие-то грабли были с libgd2, но могу и ошибаться.
Синтетические тесты типа ab и т.п. эти грабли никогда не находят, а вот в реальной эксплуатации они возникают.
Поэтому у нас используется mpm_worker + php-fcgi
работает, правда пару патчей на старые php пришлось наложить