Релиз http-сервера nginx 1.2.7

12.02.2013 21:13

Представлен новый релиз в стабильной ветке высокопроизводительного http-сервера nginx 1.2.7. В новой версии:

Директива add_header добавляет строки в ответы с кодом 201;
В директиву geo и модуль ngx_http_geoip_modul добавлена поддержка IPv6;
В директиву access_log добавлена поддержка параметров flush и gzip;
В директиве auth_basic теперь можно использовать переменные;
При использовании маски в директиве include, файлы теперь включаются в алфавитном порядке;
Переменные $pipe, $request_length, $time_iso8601 и $time_local теперь можно использовать не только в директиве log_format;
Налажен процесс сборки модуля ngx_http_perl_module, который не собирался в некоторых ситуациях;
Устранен крах при использовании модуля ngx_http_xslt_module;
Решены проблемы со сборкой на платформе Mac OS X;
Исправлена ошибка из-за которой при использовании директивы limit_rate с большими значениями скорости на 32-битных системах ответ мог возвращаться не целиком;
Устранена излишняя нагрузка на процессор во время согласования SSL-сеанса при использовании методов обработки соединений select, poll и /dev/poll.

исправить +14 +/–

Главная ссылка к новости (http://mailman.nginx.org/piper...)

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/36095-nginx

Ключевые слова: nginx

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (51)

1.1, lemanyk (ok), 22:08, 12/02/2013 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
>gzip и 100 лет не прошло

2.3, Andrey Mitrofanov (?), 22:52, 12/02/2013 [^] [^^] [^^^] [ответить]

+11 +/–

>>gzip
> и 100 лет не прошло

В директиве access_log? Кому она там сдалась?

Идейному подполью в тайной битве с логротейтом?
Или строителям комбайнов для битвы за Урожай?

3.6, Picker (?), 01:31, 13/02/2013 [^] [^^] [^^^] [ответить]	–1 +/–
Когда у вас будет штатная нагрузка в 50000rps, то вы ощутите, что такое писать логи.

4.9, Аноним (-), 09:07, 13/02/2013 [^] [^^] [^^^] [ответить]	+13 +/–
Угу - и в такой момент gzip тебе резко поможет! :-)

5.14, Andrey Mitrofanov (?), 14:13, 13/02/2013 [^] [^^] [^^^] [ответить]

+/–

> Угу - и в такой момент gzip тебе резко поможет! :-)

Если Вы немного подумаете, но уменьщение конкретной операции записи раз в 6, скажем, при исходном 50К * 100б / с, например, на фоне "прочей" загрузки...

...да, тааааак поможет.

6.20, XoRe (ok), 14:55, 13/02/2013 [^] [^^] [^^^] [ответить]

+/–

>> Угу - и в такой момент gzip тебе резко поможет! :-)
> Если Вы немного подумаете, но уменьщение конкретной операции записи раз в 6,
> скажем, при исходном 50К * 100б / с, например, на фоне
> "прочей" загрузки...
> ...да, тааааак поможет.

... и бутылочным горлышком станет проц.

Теперь есть три способа писать в логи:
- если быстрая дисковая подсистема - на диск;
- если быстрый проц - в gzip;
- если много оперативки - в tmpfs;

Каждый выбирает по вкусу.
Не хватает только пулять логи в пространство по udp, как pinba.

7.37, Аноним (-), 11:28, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
> ... и бутылочным горлышком станет проц. Ну если это i386 - конечно. А например на быстром серваке который статику льет и в основном ждет реакции дисков - ровно наоборот.

5.16, Аноним (-), 14:35, 13/02/2013 [^] [^^] [^^^] [ответить]	+/–
> Угу - и в такой момент gzip тебе резко поможет! :-) Поможет как ни странно, если процессор мощный. Сократит объем I/O. Кто не верит - может посмотреть на примере бенчей btrfs на форониксе как включение сжатия может повышать скорость работы с диском...

4.13, o (?), 12:22, 13/02/2013 [^] [^^] [^^^] [ответить]	–3 +/–
то что nginx вальнется от такой нагрузки в первую же секунду даже ни нитересно. Интересно сколько он успеет обработать. Первых тыс 20?

5.34, Picker (?), 10:56, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
http://lowlatencyweb.wordpress.com/2012/03/26/500000-requestssec-piffle-10000 1 000 000 запросов в секунду обрабатывает и не валится.

6.35, o (?), 11:00, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
1200 клиентов, это очень не много. И почему дальше не промеряли? Дальше результаты совсем не такие радужные?

7.36, Picker (?), 11:08, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
Дальше всё упирается в ОС и сетевой стэк. Nginx пофиг в общем сколько соединений будет. Вот другие примеры: https://signup.netflix.com/openconnect/software - эти перцы генерят около трети всего мирового интернет трафика. https://barry.wordpress.com/2008/04/28/load-balancer-update/ - 9k без проблем в 2008-ом году. Сейчас наверное у них в разы больше.

8.45, o (?), 14:04, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
ну так прочитали бы сами сначала 8-9k requests second and about 1 2Gbit sec t... текст свёрнут, показать

9.46, Picker (?), 04:00, 16/02/2013 [^] [^^] [^^^] [ответить]	+/–
Only software we tested which could handle 8000 live traffic, not benchmark re... текст свёрнут, показать

10.48, Picker (?), 04:06, 16/02/2013 [^] [^^] [^^^] [ответить]	+/–
Сейчас они уже другие числа приводят The only software tested that was capable ... текст свёрнут, показать

7.38, Аноним (-), 11:41, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
> 1200 клиентов, это очень не много. 1200 _одновременных_ клиентов это достаточно приличный результат. Более того, симуляция такого количества клиентов сама по себе жрет нетривиально ресурсов.

5.39, Аноним (-), 11:44, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
> то что nginx вальнется от такой нагрузки Чего бы это вдруг? Он такие нагрузки тянет с регулярностью чартерных рейсов на куче высоконагруженных сайтов. И если у вас что-то отваливается - вопросы к рукам, ОС или что там у вас еще кривое.

4.27, Michael Shigorin (ok), 16:31, 13/02/2013 [^] [^^] [^^^] [ответить]	+/–
> то вы ощутите, что такое писать логи buffer=64k или сколько удобно точно добавили?

5.29, Andrew Kolchoogin (?), 22:15, 13/02/2013 [^] [^^] [^^^] [ответить]

+/–

>> то вы ощутите, что такое писать логи
> buffer=64k или сколько удобно точно добавили?

Да это не поможет, если писать сильно подробные логи. Всё равно disk I/O всё скушает. А не писать подробные логи многим стрёмно, типа "вдруг поломают -- откуда я узнаю, через что?"

Аргументация вида "nginx -- система отдачи статического контента и прокси для FastCGI/WSGI/whatever, через статику не ломают, а логи динамики пишите на бэкендах" народ не устраивает.

6.30, Michael Shigorin (ok), 23:46, 13/02/2013 [^] [^^] [^^^] [ответить]	+/–
> Да это не поможет, если писать сильно подробные логи. Всё равно disk > I/O всё скушает. Тогда логи складывать на отдельный шпиндель/массив.

7.31, Аноним (-), 14:31, 14/02/2013 [^] [^^] [^^^] [ответить]	+/–
... с отдельным оптическим контроллером и хост-адаптером по конской цене....

1.2, fi (ok), 22:21, 12/02/2013 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Интересно, а websocket он уже научился?

2.4, Linux_RIP (?), 23:05, 12/02/2013 [^] [^^] [^^^] [ответить]	+/–
нет, tcp_proxy тоже мало помогает

2.5, Аноним (-), 00:21, 13/02/2013 [^] [^^] [^^^] [ответить]	+3 +/–
http://trac.nginx.org/nginx/milestone/1.3.13

3.7, бутират (?), 06:53, 13/02/2013 [^] [^^] [^^^] [ответить]	–4 +/–
Почти пустая страничка. Не могли бы обьяснить что это? Это сторонняя разработка или родная?

1.8, CSRedRat (ok), 07:57, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]	+/–
>Исправлена ошибка из-за которой при использовании директивы limit_rate с большими значениями скорости на 32-битных системах ответ мог возвращаться не целиком; Доставляет, что раньше были распространены баги с распространением 64-разрядных систем у пользователей, а теперь с практически отсутствием 32-разрядных систем у разработчиков.

2.22, XoRe (ok), 14:57, 13/02/2013 [^] [^^] [^^^] [ответить]

+1 +/–

>>Исправлена ошибка из-за которой при использовании директивы limit_rate с большими значениями скорости на 32-битных системах ответ мог возвращаться не целиком;
> Доставляет, что раньше были распространены баги с распространением 64-разрядных систем
> у пользователей, а теперь с практически отсутствием 32-разрядных систем у разработчиков.

Наверное мало где большой limit_rate у 32битных систем.

1.10, slowpoke (?), 09:35, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]	–3 +/–
интересно они CGI впилят все же когда нибудь или нет?

2.11, Аноним (-), 09:59, 13/02/2013 [^] [^^] [^^^] [ответить]	+3 +/–
Нет.

2.12, arka (?), 10:06, 13/02/2013 [^] [^^] [^^^] [ответить]	+3 +/–
А зачем он там внутри, есть fcgiwrap

3.15, slowpoke (?), 14:33, 13/02/2013 [^] [^^] [^^^] [ответить]	–5 +/–
это геморрой на ровном месте. вместо того чтобы просто запустить мой CGI

4.19, Аноним (-), 14:41, 13/02/2013 [^] [^^] [^^^] [ответить]	+1 +/–
> это геморрой на ровном месте. вместо того чтобы просто запустить мой CGI Легкий и быстрый сервер и CGI - взаимоисключающие параграфы. Если вас интересует CGI, вам априори класть на скорость работы этого барахла и нагрузку на сервер. Нафига вам тогда нжинкс, собственно?

5.24, slowpoke (?), 15:24, 13/02/2013 [^] [^^] [^^^] [ответить]	–6 +/–
на этапе разработки чистый CGI удобней. удобно написать CGI прототип потом уже прикрутить FastCGI. я же не предлагаю выпилить FastCGI, я предлагаю впилить CGI. В мануале можно специально оговорить что это не подходит для высоких нагрузок.

6.25, Andrey Mitrofanov (?), 15:29, 13/02/2013 [^] [^^] [^^^] [ответить]	+2 +/–
> на этапе разработки чистый CGI удобней. удобно написать CGI прототип Знаем мы таких "разработчиков", которым на этом этапе разработки удобно флудить на опеннетах, вместо поставить - на этом этапе разработки! - апач, вебрик или кого бы там там ни. Сами такие! //Минус разработка.

7.26, slowpoke (?), 15:36, 13/02/2013 [^] [^^] [^^^] [ответить]	–6 +/–
вот про то и речь что нафига мне апач если все одно потом будет и fastcgi и nginx?

8.41, Аноним (-), 11:53, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
Ну так пишите сразу под фасту и не выделывайтесь Самолет хорошо получается если... текст свёрнут, показать

6.40, Аноним (-), 11:52, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
Удобнее чем что Например FastCGI - это совершенно иной протокол с совершенн... большой текст свёрнут, показать

7.50, slowpoke (?), 10:19, 19/02/2013 [^] [^^] [^^^] [ответить]	+/–
>Придется всю логику перекраивать. На вообще фундаментальном уровне. Кроме гомерического смеха это ничего не вызывает. Знаете у меня вот совершенно нет проблем создавать прототип на CGI и потом превращать его в полноценный FastCGI. Но поскольку nginx CGI не умеет приходится извращаться. Если они впилят эту возможность извращаться не нужно будет и мир станет лучше вот и все.

6.47, Picker (?), 04:03, 16/02/2013 [^] [^^] [^^^] [ответить]	–1 +/–
> на этапе разработки чистый CGI удобней. удобно написать CGI прототип потом уже > прикрутить FastCGI. я же не предлагаю выпилить FastCGI, я предлагаю впилить > CGI. В мануале можно специально оговорить что это не подходит для > высоких нагрузок. Вы там что, на Си пишете? Осильте уже Django и подобные, как и во всех нормальных веб-фреймворках, там есть встроенный http сервер для разработки из коробки, одной командой запускается.

7.51, slowpoke (?), 10:23, 19/02/2013 [^] [^^] [^^^] [ответить]	+/–
> Вы там что, на Си пишете? Я прототип хочу писать на чем угодно. И CGI это позволяет - хоть на bash. И это хорошо.

4.21, Andrey Mitrofanov (?), 14:56, 13/02/2013 [^] [^^] [^^^] [ответить]

+/–

> это геморрой
> мой CGI

Так! И subj тут не при чём. //Да, тролить-флудить само собой.

4.23, XoRe (ok), 14:58, 13/02/2013 [^] [^^] [^^^] [ответить]

+1 +/–

> это геморрой на ровном месте. вместо того чтобы просто запустить мой CGI

И ждать, пока он запустится?
Осильте написать fastcgi wrapper для вашего CGI.

5.42, Аноним (-), 11:54, 15/02/2013 [^] [^^] [^^^] [ответить]

+/–

> Осильте написать fastcgi wrapper для вашего CGI.

Или хотя-бы готовый взять. Их есть. Только это апгрейд запорожца в самолет путем обработки напильником.

3.17, slowpoke (?), 14:35, 13/02/2013 [^] [^^] [^^^] [ответить]	+/–
> А зачем он там внутри, есть fcgiwrap не говоря о том что это сторонняя тулза которой нет в пакете с nginx

4.44, Аноним (-), 11:57, 15/02/2013 [^] [^^] [^^^] [ответить]

+/–

> не говоря о том что это сторонняя тулза которой нет в пакете с nginx

Потому что никто не собирается делать из ваших узкоспециализированных закидонов себе проблему. Это так сложно осознать?

2.18, Аноним (-), 14:39, 13/02/2013 [^] [^^] [^^^] [ответить]	+1 +/–
> интересно они CGI впилят все же когда нибудь или нет? Никогда. И правильно делают.

3.32, Аноним (-), 14:32, 14/02/2013 [^] [^^] [^^^] [ответить]	–1 +/–
>> интересно они CGI впилят все же когда нибудь или нет? > Никогда. И правильно делают. Для вящей безопасности. CGI только ленивый не ломал.

4.43, Аноним (-), 11:56, 15/02/2013 [^] [^^] [^^^] [ответить]	+/–
> Для вящей безопасности. CGI только ленивый не ломал. Самому по себе CGI поводов ломаться не больше чем чему-то еще. А вот скорость у него мерзостная и любой умник может положить сервак просто сделав много запросов к оному. Далее сервак наделает зиллионы форков и тихо загнется, вплоть до выжирания всех ресурсов операционки под ноль. Ну или у хорошего админа упрется в лимиты и просто тихонько забьет на обслуживание легитимных клиентов.

2.28, Andrew Kolchoogin (?), 22:13, 13/02/2013 [^] [^^] [^^^] [ответить]	+1 +/–
Для корректной обработки CGI необходимо, чтобы Web-сервер умел делать fork()/exec() на каждый реквест страницы. Nginx этого не будет уметь делать _никогда_.

2.33, dolphin (??), 15:31, 14/02/2013 [^] [^^] [^^^] [ответить]	+/–
Сначала матчасть почитайте, тогда поймёте почему в nginx никогда не будет CGI. Если совсем коротко - nginx это FSM (КА по-русски), а не multithreaded как апач. Потому он и быстр и не прожорлив. По тому-же Сысоев всегда был против логирования в сислог. Нужен CGI - используйте врапперы или апач, не мешайте nginx работать.

3.49, slowpoke (?), 10:16, 19/02/2013 [^] [^^] [^^^] [ответить]	+/–
это вы матчасть почитайте апач делает форки а не треды. я прекрасно умею работать как с CGI так и с FastCGI. "nginx был бы удобней если в нем была бы встроенная возможность запускать CGI" это ровно то что я хотел сказать. то что FastCGI быстрее я как бы знаю

Добавить комментарий

Текст: