Re: nginx + CGI

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Wed, Jan 14, 2009 at 03:48:05PM +0200, MZ wrote:

> В ср, 14/01/2009 в 15:57 +0300, Igor Sysoev пишет:
> > On Wed, Jan 14, 2009 at 01:46:48PM +0200, MZ wrote:
> > 
> > > Если будет реализован первый вариант, то реализация второго тривиальна -
> > > запускаем специальный nginx который будет заниматься только!
> > > cgi-запросами, а дальше на него форвардить запросы по классической
> > > схеме.
> > > Этот специальный nginx может работать как в standalone режиме так и
> > > запускаться отдельным воркером (аналог cgid в апаче2).
> > 
> > И чем это отличается от nginx/mini_httpd ?
> 
> Тем что это nginx, а не mini_httpd :)
> 
> Низкая нагрузка на сервер - основное преимущество перед mini_httpd
> 
> Согласен что по сравнению с оверхедом на работу cgi этого можно и не
> заметить, но не все ж для cgi только perl используют.

Откуда там будет низкая нагрузка ? mini_httpd делает fork/fork/exec,
nginx будет делать fork/exec. Судя по lmbench, на PentiumM 1.7GHz можно
сделать 2500 fork/fork/exec и 4600 fork/exec в секунду. Всё это
несопоставимо с CGI. Хотя CGI и может обработать несколько десятков
запросов в секунду, это метод для нескольких запросов в минуту (мониторинг,
статистика и тому подобное), потому что там, где есть десятки в секунду
могут неожиданно появиться сотни и тысячи и всё станет раком.

> Кроме того, функциональность по запуску cgi можно будет использовать для
> запуска и управления fcgi-воркерами, то есть встроить fcgi-менеджер
> процессов в nginx, что опять же дает выигрыш в нагрузке на сервер.
> 
> Исходя из того что архитектура nginx идеально подходит для проксирования
> сетевых потоков данных, её стоит использовать где это происходит, то
> есть в cgi- и fcgi-менеджерах, которые как раз и занимаются
> приемом/передачей данных через сокеты.

А как себя будут вести разделяемые кэши акселераторов PHP, если PHP-процессы
будут запускаться не PHP-процессом, а fcgi-менеджером ?

> > > Ну и надо предусмотреть возможность работы такого воркера (который будет
> > > обслуживать только cgi) из под рута для suexec, для standalone варианта
> > > достаточно будет просто указать user root; в основном конфе.
> > > 
> > > В ср, 14/01/2009 в 13:08 +0300, Igor Sysoev пишет:
> > > > On Tue, Jan 13, 2009 at 08:12:26PM +0300, Сергей Волков wrote:
> > > > 
> > > > > 13 января 2009 г. 17:28 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> 
> > > > > написал:
> > > > > 
> > > > > > On Mon, Dec 29, 2008 at 08:17:19AM +0300, Khramov Anton wrote:
> > > > > >
> > > > > > > Я понимаю, что для _быстрого_ web сервера CGI не приемлем, но увы
> > > > > > приходится изобретать велосипед в виде fastcgi -> cgi конвертера 
> > > > > > или nginx
> > > > > > proxy -> mini_httpd.
> > > > > 
> > > > > > Нет. Реализация менеджера CGI в nginx'е - не самая тривальная 
> > > > > > задача,
> > > > > 
> > > > > Здается мне что написать некий nginx-cgid(FastCGI враппер) со всеми
> > > > > прелестями suexec-ка плюс всякие чруты/улимиты написать не настолько 
> > > > > сложная
> > > > > задача. осталось найти писателя :-)
> > > > > IMO данная софтулена мгновенно найдет своих потребителей, а nginx 
> > > > > приобретет
> > > > > удобную поддержку CGI приложений.
> > > > 
> > > > Это не сложная задача. Эта задача требует времени. Есть два решения:
> > > > 
> > > > 1) В лоб: воркер, который получил запрос для CGI, делает fork/exec.
> > > > 
> > > > 2) Правильное решение: специальный процесс, работающий от рута (для 
> > > > suexec),
> > > >    которому через unix-сокеты передаются сокеты клиента, а он для них
> > > >    делает fork/exec.
> > > > 
> > > > Второй вариант по сути ничем не отличается от nginx/mini_httpd, а вот
> > > > времени на него мне жалко.
> > > > 
> > > > 
> > 

-- 
Игорь Сысоев
http://sysoev.ru