nginx + CGI

[MZ]

В пн, 29/12/2008 в 14:43 +0000, Valery Kholodkov пишет:
> Я могу ошибаться, но в дистрибутиве fastcgi, насколько я помню, есть
> cgi-враппер. Так или иначе, я не верю, что не существует нативной
> реализации cgi-враппера для fastcgi.
> 
> И кроме того, написание cgi-враппера для fastcgi на C -- это не
> домашнее ли задание после прочтения документации по fastcgi?

Можно и http-враппер к cgi-написать на C
Можно хороший и многофункциональный, типа apache.
Можно и дубовый.
Можно и вообще на перле - и тоже будет работать.
А можно и без враппера обойтись, и запускать cgi нативно - и это будет
самый производительный вариант.

> ----- Original Message -----
> From: "MZ" <zuborg at advancedhosters.com>
> To: nginx-ru at sysoev.ru
> Sent: Monday, December 29, 2008 3:18:37 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: RE: nginx + CGI
> 
> В пн, 29/12/2008 в 15:54 +0200, maxhl at hitline.net.ua пишет:
> > >Правильно, получится практически полноценный веб-сервер
> > >nginx с поддержкой cgi, быстрый и оптимизированный, с поддержкой kqueue,
> > >все дела.. И даже новоявленный переделаный из http-парсера парсер
> > >fcgi-запросов можно выбросить. А можно и оставить - чем плохо иметь
> > >веб-сервер который умеет и http и fcgi ?
> > 
> > Неправильно. Nginx это уже полноценный веб-сервер. CGI программы пишут, как
> > правило сомнительные программисты чтобы скрыть свой непрофессианализм.
> > Почему Вас совершенно не смущает невозможность миграции так называемых
> > cgi-програм с linux под win? а иногда даже с linux под freebsd ...
> > умудряются же так скомпилировать ... :-))) Ну а про большие нагрузки вообще
> > и речи быть неможет ... Используйте lighthttpd вполне работоспособная связка
> > ... если нужен клиентсткий ip то можно первый апач прикрутить предварительно
> > викинув из него все ненужное он от этого похудеет до 1м в памяти ... 
> > Нужно понимать разницу между nginx и apache. Поищите здесь по форуму - nginx
> > заточен на обработку не блокирующих-ся запросов. Тоесть запросов которые
> > пришли - ушли, в них недолжно быть долгих вычислений, коннектов к базе. В
> > этом весь смысл !!! Именно поэтому два воркера nginx справляются со всей
> > нагрузкой. Ваши cgi программы это 100% блокирующие-ся запросы... они будут
> > что то считать, коннектиться к базе и на время пока они не отдадут ответ
> > соответствующие воркеры будут блокированы - то есть не смогут обрабатывать
> > другие запросы. Поэтому Вам понадобится не 2 воркера а 200 ... 2000 ... в
> > зависимости от нагрузки. Именно поэтому нельзя на встроенном в nginx perl
> > писать cgi приложения ... а хочетца :-)
> > Пускалка cgi нужна на с++ и хорошо бы ей уметь работать через unix-socket
> > ... 
> > 
> > С уважением Max 71006063
> 
> Шутить изволите. Почему-то для того чтобы передавать ответ из сокета
> fcgi-сервера или http-бекенда не надо блокировок, а вот для вывода
> stdout-а cgi-программы уже вдруг надо заблокироваться, так, что ли?
> Блокировка работы cgi-программы точно такая же как и у воркера fcgi, и
> тех и других может быть много что не никоим образом не мешает работать
> nginx-у
> 
> Ещё раз повторюсь - я нигде и не коим образом не говорю что fcgi это
> плохо и весь fcgi софт надо срочно переводить на cgi? fcgi это
> действительно очень (а может и самый) правильный подход к генерации
> динамического контента.  И для одновременной генерации ответов на 200
> запросов все равно понадобится 200 процессов или хотя бы тредов, как не
> крути.
> 
> Смысл моего поста в том что не надо писать fcgi-прокси на перле когда
> уже есть готовый http-прокси - nginx, который можно доделать для
> поддержки cgi и получить гораздо! большую производительность чем если бы
> проксированием fcgi->cgi занимался перл.
>