LINUX.ORG.RU

nginx 0.9.1 и анонс nginx user group

 


0

2

За последние время в мире Nginx произошло несколько важных событий, которые не получили огласки.

Статус версии 0.8.x изменён на стабильный. Во время разработки этой версии, среди прочего, появились

  • поддержка именнованых выделений в регулярных выражениях,
  • поддержка файлового AIO во FreeBSD и Linux,
  • SSL CRL,
  • модули SCGI и uwsgi.

Релиз с новой функциональностью 0.9.0 и bugfix релиз 0.9.1

И 16 декабря состоится первая встреча Nginx User Group с которой будет доступна запись и в рамках которой будет доклад про конфигурирование Nginx.

>>> Подробности

★★★★★

>модули SCGI и uwsgi

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

xhat ()

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

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

kranky ★★★★★ ()

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

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

catap ★★★★★ ()
Ответ на: комментарий от xhat

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от kranky

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

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

bromm ()

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

bernd ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от catap

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

mine ()
Ответ на: комментарий от catap

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

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

...

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от mine

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

anonymous ()
Ответ на: комментарий от KRoN73

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

и только?

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

AVL2 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Laz ★★★★ ()
Ответ на: комментарий от anonymous

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

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

...

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от AVL2

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

shelA ()
Ответ на: комментарий от anonymous

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

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

scaldov ★★ ()
Ответ на: комментарий от kranky

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

kostian ★★★★☆ ()
Ответ на: комментарий от mine

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

catap ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от shelA

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

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

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

anonymous ()
Ответ на: комментарий от KRoN73

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

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

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

AVL2 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от AVL2

лайти научился делать оное только в 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"

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от AVL2

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

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

anonymous ()
Ответ на: комментарий от KRoN73

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

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

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

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

pinachet ★★★★★ ()
Ответ на: комментарий от pinachet

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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


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

$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" ),
)

}

AVL2 ★★★★★ ()

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

pi11 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от KRoN73

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

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

anonymous ()
Ответ на: комментарий от Vit

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.