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

Ничо так, гламурненько. Но нифига нового - просто вольное изложение манов.

+1

ага блин, а потом руководство по переписыванию PHP-скриптов так, чтобы они работали под CGI

Кстати, это только у меня php не рестартует после указаного кол-ва запросов при использовании встроенного в php сервера? При использовании spawn-fcgi такой проблемы нет :( И можно ли используя встроеный сервер сделать не ТСР-сокет а UNIX?

>И можно ли используя встроеный сервер сделать не ТСР-сокет а UNIX?
можно!

nginx - это тот сервер, на котором почти постоянно выдаётся "gateway connection timeout" или что-то в этом роде? :)

> nginx - это тот сервер, на котором почти постоянно выдаётся "gateway

> connection timeout" или что-то в этом роде?

ОН.

как настроено то и выдает

Как? Если делать несколько сокетов - можно для каждого свой php.ini ?

А что плохого в этом сообщении? То, что perl\php\python падает на серваке - не вина nginx'a ;)

эх ещё бы в строенном сервере пхп как то прикрутить openssl и было бы полное счастье

>nginx - это тот сервер, на котором почти постоянно выдаётся "gateway connection timeout" или что-то в этом роде? :)

+1

и не только это :)))

что не лежачий сервер в рунете - то ngnix ;)

> ага блин, а потом руководство по переписыванию PHP-скриптов так, чтобы они работали под CGI

Бред какой. Разницу между mod_php и FastCGI-php можно почуствовать только если пользоваться basic auth в apache и логин с паролем пытаться средствами php проверять. При этом разница будет в том что логин будет в другую переменную передан (с другим именем). Это если руки у настраивавшего php из нужного места растут.
А если говорить про переход под nginx вместо apache, то скорее проблемой станет несовместимость между директивами mod_rewrite, mod_actions и т.п., прописанными в .htaccess и nginx'ом, который их разумеется не понимает.

я что то невижу смысла во всей это свистопляске если сайт исключительн динамика, какой нахрен толк от 2х машин вместо одной ? в 2 раза бабла больше нада ))))))) а то что одна принимает запрос а другая обрабатывает гм, и чо мега быстро чтоли буит ? с таким же успехом мона просто слепить 2х нодовоый HA/LB кластер... з.ы. туфта какаета.

>>nginx - это тот сервер, на котором почти постоянно выдаётся "gateway >connection timeout" или что-то в этом роде? :)

>+1

>и не только это :)))

>что не лежачий сервер в рунете - то ngnix ;)

тут nginx не причина, а следствие.

> я что то невижу смысла во всей это свистопляске если сайт исключительн динамика, какой нахрен толк от 2х машин вместо одной ? в 2 раза бабла больше нада ))))))) а то что одна принимает запрос а другая обрабатывает гм, и чо мега быстро чтоли буит ? с таким же успехом мона просто слепить 2х нодовоый HA/LB кластер... з.ы. туфта какаета.

Ну вопервых 2 машинки необязательно, во вторых (по личному опыту) перевод с апачь+mod_php на nginx+php-fcgi+eaccel дало прирост с ~500q/s до ~2000q/s без замены железа.

так погодите, вы имете ввиду что на одной машине нгникс +пхп фаст сги в разы быстрее чем апач + мод пхп, ну ЧЕСНО - неверю.

> так погодите, вы имете ввиду что на одной машине нгникс +пхп фаст сги в разы быстрее чем апач + мод пхп, ну ЧЕСНО - неверю.

если без eaccell то толку (кроме экономии памяти) можно считать никакого.

>так погодите, вы имете ввиду что на одной машине нгникс +пхп фаст сги в разы быстрее чем апач + мод пхп, ну ЧЕСНО - неверю.

Зависит от задач. Если 90% времени работает СУБД, производительность особо не улучшится.

Если 90% времени в самом PHP - то тоже.

А вот если бОльшую часть запроса составляет его отдача клиенту - то да, возрастет и сильно.

ага, ясно, пхп на моих задачах - 80%, проблем с отдачей невозникало.... пасибо за разьяснения.

так пока никаких проблем нету - какой смысл чтото менять? на приключения нарватся охота? (;

>так погодите, вы имете ввиду что на одной машине нгникс +пхп фаст сги в разы быстрее чем апач + мод пхп, ну ЧЕСНО - неверю.

Это действительно так. Но из таких легковесных веб-серверов я лично предпочитаю lighttpd (лайти - http://www.lighttpd.net/).

Это как же писать надо, даже на пыхпых, чтоб такое добиться?

PS. nginx не пользую, а вот lighttpd+php-fcgi есть немножко.

RTFM

> так погодите, вы имете ввиду что на одной машине нгникс +пхп фаст сги в разы быстрее чем апач + мод пхп, ну ЧЕСНО - неверю.


Ну и напрасно. Даже apache 2 с mpm_worker (многопоточным) и php-fcgi работает быстрее традиционного preforked-apache. Быстрее за счет более быстрой отдачи статики, сам по себе php-fastcgi работает точно так же как mod_php. А nginx статику должен отдавать быстрее апача. Так что .. :)

даже в случае apache+mpm worker нгникс буит быстрее ? гм, ну хоть тады какиенибуть бенчи в студию.....

Сам неожидал. Был апач, система биллинга клуба, в основном работа с базой и пхп, отдача инфы через соап - на 190-200 машинах атлон 3400 затыкался, после перехода на нгинкс с фаст сги (уже незнали что и делать решили попробовать) - загрузка в среднем 5-10% до 30% - до сих пор толком немогу обьяснить.

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

>я что то невижу смысла во всей это свистопляске

Это потому что ты дятел.

>если сайт исключительн динамика, какой нахрен толк от 2х машин вместо одной ? в 2 раза бабла больше нада )))))))

не в 2 раза больше, а в 1.5 меньше.

Связка nginx+php/FCGI работает примерно в три раза быстрее апача, при гораздо более скромном потреблении рамы.

> А что плохого в этом сообщении? То, что perl\php\python падает на серваке - не вина nginx'a ;)

Плохо то, что этот nginx не в состоянии нормально перезапустить упавший FactCGI-сервер.

ЗЫ Пользуюсь lighttpd =)

1) дятел у тебя в зеркале, сынок 2) в случае 1 машины это очень маловероятно, единственаня фишка так это в экономии памяти 3) про стабильность этой связки тут уже говорили..... 4) чем эта ботва будет лучше 2х нодовова кластера ? з.ы. цены на память сецчас знаеш ли мягко говоря не высокие, и как это еще нада увязать с особенностями работы скриптов в режиме cgi, посравнению с простым кластером ваше решение выглядит гемороем.

какое нахрен это решение када пол рунета сверкают овталившимися fastcgi серваками епт

Час моего времени, потраченного на настройку этой поделки, стоит дороже, чем докупить памяти на сервак.

+1

Прочитал как Руководство по использованию nginx + PHP в режиме GetTheFacts :-)

нафиг! лучше Lighttpd и SCGI есть. с ним и пошустрей и по-проще

>нафиг! лучше Lighttpd и SCGI есть. с ним и пошустрей и по-проще

+1

mod_worker + mod_php + реверсный проксик - замечательно работает. Не подходит только эстетам, сидящим на 1.3

Неужели проще поставить нечто новое вместо того, чтобы хорошо изучить возможности старого??

Иногда вольное изложение манов, да ещё и на русском - весьма полезно

> mod_worker + mod_php + реверсный проксик - замечательно работает. Не подходит только эстетам, сидящим на 1.3

А чем это лучше чем, к примеру, lighttpd и FastCGI? Тем что медленнее и прожорливее, как и пологается солидному серверному ПО? :-P Или юзать апач для Вас самоцель? :)

Бенчей apache vs nginx у меня нет, просто я читал о том как работает nginx и за счет чего собственно у него достигается то, что он работает быстрее апача.
А именно:
1. apache + mpm_prefork - соответственно работает за счет пула заранее отфорканных child'ов. Это самый тормозной вариант + самый накладный по памяти, т.к. каждый коннект будет стоить копии апача со всеми модулями в памяти
2. apache + mpm_worker - пул 3-4 заранее отфорканных child'ов, каждый из которых является многопоточным, таким образом на обслуживание коннекта выделяется отдельный поток, соответственно памяти требуется всего на 3-4 копии апача + на потоки. В этом варианте mod_php не работает, зато отлично работает fastcgi
3. nginx - это на сколько я в курсе мультиплексирующий веб-сервер, он работает быстрее многопоточного и имеет меньший оверхэд и меньшее потребление памяти.

Как это "с mod_worker неработает"??? 8-[ ]

> In case you wish to build a multithreaded version of Apache 2.0 you must overwrite the standard MPM-Module prefork either with worker or perchild. To do so append to your configure line in step 6 above either the option --with-mpm=worker or --with-mpm=perchild.

Я даж на php.net зашёл посмотреть не дурак ли я...

> мультиплексирующий веб-сервер

Это что за зверь-то? Через select() сокеты перебирает? :-)

>Это что за зверь-то? Через select() сокеты перебирает? :-)

Почему обязательно через select?

Можно перебирать через kqueue, epool, poll, RT signals...

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

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

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

ngx_connection_t *
ngx_get_connection(ngx_socket_t s, ngx_log_t *log)
{
    ngx_uint_t         instance;
    ngx_event_t       *rev, *wev;
    ngx_connection_t  *c;
[-- SKIP --]
    c = ngx_cycle->free_connections;
[-- SKIP --]
    rev = c->read;
    wev = c->write;
    ngx_memzero(c, sizeof(ngx_connection_t));
    c->read = rev;
    c->write = wev;

В целом - похоже на продолжение разработки дипломной работы "Написание однопоточного 
HTTP-сервера/IMAP-proxy". Отсюда и метод работы выдранный из SQUID. 
Да и работа с модулями как у Apache 1.3.

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

Ха-ха-ха.
worker+php -- хорошая шутка, да, я оценил.
/me плачет

> Как это "с mod_worker неработает"??? 8-[ ]

Собирается.. И даже немножко работает.. Но как только начинается нагрузка, сушите весла.

> Собирается.. И даже немножко работает.. Но как только начинается нагрузка, сушите весла.

А вот с этого момента с подробностями пожалуйста. ОСь, как собирали, как проявляется "сушите вёсла" и т.п... Какая нагрузка?

>1. apache + mpm_prefork - соответственно работает за счет пула заранее отфорканных child'ов. Это самый тормозной вариант + самый накладный по памяти, т.к. каждый коннект будет стоить копии апача со всеми модулями в памяти

вроде как система виртуальной памяти в любой нормальной операционке решает эту проблему.

> А вот если бОльшую часть запроса составляет его отдача клиенту - то да, возрастет и сильно.

Файловый сервер на php? Оригинально :)

> Файловый сервер на php?

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