nginx + CGI

[Kostya Alexandrov]

имхо, если у Вас запросы с cgi бекендом редкая операция, то поставте 
апач или лайт и т.п,
если их даже дестяки (не говорю о сотнях) в секунду, то Вы просто убъете 
всю систему
огромным количеством процессов. Такой у меня был пусть с апача на nginx. 
когда количество
кипаливных соединений дошло до определенного 1200 или типа того, то 2.4 
линуксы просто
стали заниматься исключительно context switch и более ничем. Cgi в nginx 
сделает его апачем,
Если cgi уж так важен, и хочется иметь фроненд с мультиплексированным 
io, то смотрите
на апач 2.2 с event моделью воркеров, игал с год назад - впринципе 
живой, если без ssl, как
щас дела там незнаю.

Если есть сырцы cgi, то не так уж и проблематично превратить их в fcgi, 
либо оставить как есть,
либо сделать все заново.

MZ wrote:
> В пн, 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 занимался перл.
>>
>>