nginx 0.9.1 и анонс nginx user group

>модули SCGI и uwsgi

значит ли это, то что питон можно гонять на nginx «из коробки»?

да

>Статус версии 0.8.x изменён на стабильный

Значит ли это, что он теперь выдаёт ERROR 500 стабильно, а не случайным образом?

http://wiki.nginx.org/HttpUwsgiModule

сдается мне что нужно uwsgi-сервак поднимать чтоб nginx работал с питоновским приложениями

для сервера, просто выдающего 500 ошибку, nginx слишком сложен.

http://ru.gentoo-wiki.com/wiki/Nginx%2Bdjango#.D0.98.D1.81.D0.BF.D0.BE.D0.BB....

такие дела

nginx не решает проблему, в следствии которой появляется 500 ошибка. Он просто прикрывает ее.

>значит ли это, то что питон можно гонять на nginx «из коробки»?

SCGI ничем не лучше FastCGI

>http://ru.gentoo-wiki.com/wiki/Nginx%2Bdjango#.D0.98.D1.81.D0.BF.D0.BE.D0.BB....

Жуткое красноглазие и xml. На lighttpd всё решается конфигом для виртуального хоста на 10 строк и инитскриптом для джанговского сайта в 30.

И без дописывания левых файликов django_wsgi и прочего - всё стандартными средствами.

>Значит ли это, что он теперь выдаёт ERROR 500 стабильно, а не случайным образом?

в чётко регламентируемых ситуациях

nginx user group... у кого-то половое созревание? :)

> сдается мне что нужно uwsgi-сервак поднимать чтоб nginx работал с питоновским приложениями

смотри на это как на сервер приложений. «Хостинг» скриптоязыков в ядре сервера (как mod_* в апаче) вчерашний день.

А почему в этих ваших интернетах только он ее и выдает постоянно?

>nginx не решает проблему

Именно поэтому в целом ряде случаев lighttpd удобнее. Так как содержит в себе полноценный fcgi-менеджер.

...

Но не могу не отметить, что nginx в этом году обошёл по скорости lighttpd :)

>А почему в этих ваших интернетах только он ее и выдает постоянно?

Потому что на Apache fcgi балуются очень редко, а в lighttpd встроенный FPM, при котором такая ошибка не случается :)

реквестуем тесты производительности

>Но не могу не отметить, что nginx в этом году обошёл по скорости lighttpd :)

и только?

С другой чтороны, в lighttpd странный обратный прокси. Мало того, что он в стабильной версии 1.49 не допускает обработку урла. Так оный еще и глюкует невозбранно.

сдается мне что нужно uwsgi-сервак поднимать чтоб nginx работал с питоновским приложениями

FYI вот тут пишут, что для wsgi лучше использовать nginx+gevent.

>реквестуем тесты производительности

Не тест, но простое измерение: http://www.linux.org.ru/jump-message.jsp?msgid=5483675&cid=5483970

...

Но пока с переводом системы на nginx не спешу. Отсутствие у него fast-cgi менеджера сильно отравляет жизнь :)

>С другой чтороны, в lighttpd странный обратный прокси

А точнее? А то или не пользовался, или не наступал.

>> сдается мне что нужно uwsgi-сервак поднимать чтоб nginx работал с питоновским приложениями

смотри на это как на сервер приложений. «Хостинг» скриптоязыков в ядре сервера (как mod_* в апаче) вчерашний день.

А в чем тогда кайф такой связки? Не проще настроить эджинкс как балансирующий прокси на ну допустим десяток инстансов черрипи или на взять что-нибудь повеселее, например торнадо.

в качестве fast-cgi менеджера не подойдет spawn-fcgi[/usr] например?

блин >_<

>в качестве fast-cgi менеджера не подойдет

Он только под PHP, не следит за состоянием процессов, не занимается их периодическим перезапуском, есть проблемы при работе нескольких сокетов и т.п.

А так - да, для nginx + PHP под Gentoo хоть какой-то вменяемый не колхозный вариант :)

Да ничего, понятно, о чём речь идёт ;)

а он хоть по FastCGI научился правильно работать, или как?

ты еще gateway timeout вспомни, а потом подумай в каком случае он возникает.

потому что nginx это только proxy, и проблема в backend.

Подскажите для Ъ, сей достойный проект уже научили работать с клиентскими сертификатами?

http://wiki.nginx.org/HttpSslModule

> в чем тогда кайф такой связки? Не проще настроить эджинкс как балансирующий прокси на ну допустим десяток инстансов черрипи или на взять что-нибудь повеселее, например торнадо.

Чего это вдруг проще? Совсем не проще. Выше где-то постили ссылку на тест производительности, gevent и uwsgi будут лучше торнадо, CherryPy вообще в конкуренты не идёт как и многое полностью сделанное на питоне (и он ещё не асинхронный сервер? Тем более не конкурент).

В конце концов это всё фреймворки, а uwsgi чистый wsgi сервер с рядом вкусностей в виде хорошей поддержки асинхронных фич: uGreen (аналог гнинлетов), поддержка stackless питона, асинхронные операции с базами и файлами, общая память между процессами и т.п.

>А точнее? А то или не пользовался, или не наступал.

ну проста же задача - отсылать отсылать все с www.myhost.ru/service/... на заданный хост без приставки /service/ в урле и в ответе сделать обратное преобразование.

лайти научился делать оное только в 1.5

петросяны с 500й ошибкой подтянулись, традиционно.

лайти научился делать оное только в 1.5

eix -e lighttpd
[I] www-servers/lighttpd
...
     Installed versions:  1.4.28

...
"/attaches/(.*)" => "/attaches-guest/$1",
...
"^/users/serge77/(.*)$" => "http://serge77.rocketworkshop.net/$1",
...
"^/users/varban(.*)$"           => "http://varban.airbase.ru/old-airbase$1",
...
"/logos/(\d+)\.png$" => "http://airbase.ru/top/logos/$1.png",
...
"/wiki/?(.*)$" => "http://la2.balancer.ru/wiki/$1"

Всё это работает уже много лет и без всяких проблем :)

>петросяны с 500й ошибкой подтянулись, традиционно.

Так источник шуток же неисчерпаемый :)

На кой _сейчас_ это говно мамонта? Уже есть официальный php-fpm, он удобнее на порядок.

>Уже есть официальный php-fpm, он удобнее на порядок.

Угу. Но PHP - не единственный fast-cgi бэкенд ;)

Остальные не нужны.

>Остальные не нужны.

Даже trac? :)

Да, предвосхищая вопрос про tracd, мало того, что опять нужно городить огрод с его запуском и контролем, так ещё у меня на сервере медианное время отклика (ab -n50 -c5) в случае fast-cgi за lighttpd составляет 174мс, а в случае tracd при прямом вызове - 610мс. 3,5 раза, однако :)

>лайти научился делать оное только в 1.5

Вроде как 1.5 мёртв. Сейчас пилят 1.4.х ветку и немного 2.0 (неторопясь).

>>в качестве fast-cgi менеджера не подойдет

Он только под PHP

Почему? Я на сях свой FCGI сервер писал и использовал spawn-fcgi. Все работало. А вот то, что он не следит за состоянием процессов - это да, плохо.

>Именно поэтому в целом ряде случаев lighttpd удобнее.

Да чисто по синтаксису удобней,да и привычка возимела своё ;)

Но не могу не отметить, что nginx в этом году обошёл по скорости lighttpd

Подробности можешь сказать.

У меня шмат жира влетел в монитор.

>Подробности можешь сказать.

Так я выше ссылку давал :) Правда, я не оценивал ещё nginx с навороченными конфигами, но вряд ли он на них сильно просядет.

Переезд на него задерживает пока только ряд временных затыков в конфигурации и всякие фишки, типа упомянутого trac'а. Скорее всего, trac оставлю на lighttpd в бэкенде за nginx. Но это ещё не скоро, условия ещё на годы вперёд потерпят :) Хоть nginx и стал быстрее, чем lighttpd, всё равно их производительность далека от затыкания на моих нагрузках.

Всё это работает уже много лет и без всяких проблем :)

и где тут прокси?

$SERVER[«socket»] == ":8080" {


$HTTP[«url»] =~ «^/monitor(/|$)» {

proxy-core.max-keep-alive-requests=0
proxy-core.max-pool-size=1
proxy-core.allow-x-sendfile = «enable»
proxy-core.allow-x-rewrite = «enable»
proxy-core.balancer = «carp»
proxy-core.protocol = «http»
proxy-core.backends = ( «localhost:2812» )
proxy-core.rewrite-request = (
«_uri» => ( «^/monitor/?(.*)» => «/$1» ),
)
proxy-core.rewrite-response = (
«Location» => ( «^https://host:8080/(.*)» => "https://host:8080/monitor/$1" ),
)

}

Я бы послушал доклад Сысоева. Надеюсь будет видео.

шел 2010-ый год, а сысоев так и не понял, что такое keep-alive и для чего это нужно... ну, и пусть себе идет...

> nginx в этом году обошёл по скорости lighttpd

по скорости выдавания «500 Server Error» nginx - непревзойденный лидер.

> На кой _сейчас_ это говно мамонта? Уже есть официальный php-fpm, он удобнее на порядок.

«говно мамонта» - это твой пых-чпых