имхо, если у Вас запросы с 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@xxxxxxxxxxxxxxxxxxx>
To: nginx-ru@xxxxxxxxx
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@xxxxxxxxxxxxxx пишет:
Правильно, получится практически полноценный веб-сервер
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 занимался перл.
