Для nginx надо fastcgi-сервер php, и сейчас есть очень хороший не то патч, не то форк – http://php-fpm.anight.org/
Ну, наверное, патч. Короче, PHP не просто начинает работать под FastCGI, а ещё и само себе FastCGI Process Manager. Работает, приятно работает – стартует мастер с воркерами, воркеры перестартовывает когда надо и так далее. Это не через какие-то корявые spawn-fastcgi запускать, тут всё настраиваемо и управляемо.
ea я ставил просто – собрав php-fpm, я стянул свежие исходники ea, напустил phpize и собрал. всё просто взяло и заработало.
На этой связке (nginx + php-fpm + ea) работает... ну, вот тест работает – http://grabli.kiev.ua/mybb/ – по итогам гонок теста там сейчас кое-что вырастет. Не форум. :)
А что до не-PHP CGI сервера, пока ещё я не определился. Здесь ведь как раз нужен «медленный» форкающийся сервер – но маленький. Думаю про http://www.acme.com/software/mini_httpd/ – он есть и в репе Дебиана, который у меня стоит на большинстве тазов. Как раз умеет CGI 1.1, и до меня как раз дошло – как же его правильно конфигурировать на кучу виртхостов.
Единственное, что не очень нравится – то, что он работает только с TCP, а я хотел бы завернуть его в unix-socket...
Последнее время мне здорово не хватало CGI-бэкенда, какого-нибудь веб-сервера, исполняющего только CGI. Разводить для этой цели апачей как-то невыгодно получается.
Вот, например, для PHP у меня отлажена связка nginx + php-fcgi (теперь с php-fpm). Офигенно работает. Добавляем какой-то кэш к PHP (я добавил eaccelerator) – вообще замечательно.
«Просто fastcgi» тоже вполне себе живут.
Что напрягает – тут похуже с разработкой становится: это ж каждую fastcgi-приблуду в конфиг сервера пропиши да озаботься запуском-перезапуском её вовремя. Отлаженные вещи, понятное дело, живут совсем хорошо.
Вывод: пока не хватает Process Manager'a для FastCGI-демонов. Скриптик spawn-fcgi от lighttpd, которым многие пользуются убог до печальности, у меня похожими самописными скриптиками и запускаются эти демоны. Но запустить-то – полдела.
И вот ещё столкнулся с тем, что нужны «просто CGI». Например, какие-то административные интерфейсы или ещё какие-нибудь монстры по объёму кода. Или системы, разрабатывавшиеся много лет и всё ещё нужные в работе. Или другие штуки, которые вызываются в тысячи или десятки тысяч раз реже других скриптов или страниц – зачем под них держать запущенным fastcgi-процесс?
По итогам копаний нашёл mini_httpd от Acme: http://www.acme.com/software/mini_httpd/
Конфигурирования там почти нет, форк сервера (собранного с SSL, что мне не нужно для бэкенда) занимает около 500к памяти со всякими своими буферами. Ставил из репозитария бинарник – надо будет попробовать собрать без SSL, посмотрим, насколько полегчает.
CGI гоняет замечательно.
Если кто-то захочет его использовать, даю совет, как нормально настроить CGI по виртхостам.
В конфиге поставить:
Теперь mini-httpd при поступлении HTTP/1.1 запроса с Host:www.example.com будет пытаться отдать что-то из каталога /etc/mini-httpd/www.example.com. Нам нужно обслужить cgi-bin, который, допустим, лежит в /var/www/example.host/cgi-bin. Что делаем:
По сути, каталог /etc/mini-httpd теперь выступает у нас конфигом виртуальных хостов.
Может быть, вы удивитесь – почему об этом надо рассказывать, оно ведь проще пареной репы – но я за последнее время столкнулся с изрядным количеством народу, которые такую настройку не понимают, считают чем-то нехорошим и ни за что не дойдут до такого решения сами. Хотя у самих под линуксами где-нибудь в /etc/rcX.d сплошные симлинки.
И да, конечно же, это не замена Apache даже на 10% функций Хорошего Индейца. Это всего лишь маленький бэкенд, запускающий CGI – ничего другого мне от него не требовалось. Никаких .htaccess и прочего – всей внешней обвеской занимается nginx и другие (впрочем, mini_httpd умеет Basic Auth – но на бэкенде-то оно не нужно).
http://php-fpm.anight.org/