Представлен (http://mailman.nginx.org/pipermail/nginx-announce/2013/00010...) новый релиз в стабильной ветке высокопроизводительного http-сервера nginx 1.2.7 (http://nginx.org). В новой версии:
- Директива 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.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2013/00010...
Новость: http://www.opennet.me/opennews/art.shtml?num=36095
>gzipи 100 лет не прошло
>>gzip
> и 100 лет не прошлоВ директиве access_log? Кому она там сдалась?
Идейному подполью в тайной битве с логротейтом?
Или строителям комбайнов для битвы за Урожай?
Когда у вас будет штатная нагрузка в 50000rps, то вы ощутите, что такое писать логи.
Угу - и в такой момент gzip тебе резко поможет! :-)
> Угу - и в такой момент gzip тебе резко поможет! :-)Если Вы немного подумаете, но уменьщение конкретной операции записи раз в 6, скажем, при исходном 50К * 100б / с, например, на фоне "прочей" загрузки...
...да, тааааак поможет.
>> Угу - и в такой момент gzip тебе резко поможет! :-)
> Если Вы немного подумаете, но уменьщение конкретной операции записи раз в 6,
> скажем, при исходном 50К * 100б / с, например, на фоне
> "прочей" загрузки...
> ...да, тааааак поможет.... и бутылочным горлышком станет проц.
Теперь есть три способа писать в логи:
- если быстрая дисковая подсистема - на диск;
- если быстрый проц - в gzip;
- если много оперативки - в tmpfs;Каждый выбирает по вкусу.
Не хватает только пулять логи в пространство по udp, как pinba.
> ... и бутылочным горлышком станет проц.Ну если это i386 - конечно. А например на быстром серваке который статику льет и в основном ждет реакции дисков - ровно наоборот.
> Угу - и в такой момент gzip тебе резко поможет! :-)Поможет как ни странно, если процессор мощный. Сократит объем I/O. Кто не верит - может посмотреть на примере бенчей btrfs на форониксе как включение сжатия может повышать скорость работы с диском...
то что nginx вальнется от такой нагрузки в первую же секунду даже ни нитересно. Интересно сколько он успеет обработать. Первых тыс 20?
http://lowlatencyweb.wordpress.com/2012/03/26/500000-request.../1 000 000 запросов в секунду обрабатывает и не валится.
1200 клиентов, это очень не много. И почему дальше не промеряли? Дальше результаты совсем не такие радужные?
Дальше всё упирается в ОС и сетевой стэк. Nginx пофиг в общем сколько соединений будет.Вот другие примеры:
https://signup.netflix.com/openconnect/software - эти перцы генерят около трети всего мирового интернет трафика.
https://barry.wordpress.com/2008/04/28/load-balancer-update/ - 9k без проблем в 2008-ом году. Сейчас наверное у них в разы больше.
ну так прочитали бы сами сначала.
"8-9k requests/second and about 1.2Gbit/sec through a few Nginx instances and have plenty of room to grow!"
8-9 тыр через несколько серваков Nginx. Это нормально. это не миллион. И не 50к и даже не мои 20К, а в НЕСКОЛЬКО раз меньше.
Only software we tested which could handle 8000 (live traffic, not benchmark) requests/second on a single server
Сейчас они уже другие числа приводят:The only software tested that was capable of reliably handling over 10,000 request per second of live traffic to WordPress applications from a single server.
Overall WordPress.com is serving about 70,000 req/sec and over 15 Gbit/sec of traffic from its NGINX powered load balancers at peak, with plenty of room to grow.
http://highscalability.com/blog/2012/9/26/wordpresscom-serve...
> 1200 клиентов, это очень не много.1200 _одновременных_ клиентов это достаточно приличный результат. Более того, симуляция такого количества клиентов сама по себе жрет нетривиально ресурсов.
> то что nginx вальнется от такой нагрузкиЧего бы это вдруг? Он такие нагрузки тянет с регулярностью чартерных рейсов на куче высоконагруженных сайтов. И если у вас что-то отваливается - вопросы к рукам, ОС или что там у вас еще кривое.
> то вы ощутите, что такое писать логиbuffer=64k или сколько удобно точно добавили?
>> то вы ощутите, что такое писать логи
> buffer=64k или сколько удобно точно добавили?Да это не поможет, если писать сильно подробные логи. Всё равно disk I/O всё скушает. А не писать подробные логи многим стрёмно, типа "вдруг поломают -- откуда я узнаю, через что?"
Аргументация вида "nginx -- система отдачи статического контента и прокси для FastCGI/WSGI/whatever, через статику не ломают, а логи динамики пишите на бэкендах" народ не устраивает.
> Да это не поможет, если писать сильно подробные логи. Всё равно disk
> I/O всё скушает.Тогда логи складывать на отдельный шпиндель/массив.
... с отдельным оптическим контроллером и хост-адаптером по конской цене....
Интересно, а websocket он уже научился?
нет, tcp_proxy тоже мало помогает
http://trac.nginx.org/nginx/milestone/1.3.13
Почти пустая страничка. Не могли бы обьяснить что это? Это сторонняя разработка или родная?
>Исправлена ошибка из-за которой при использовании директивы limit_rate с большими значениями скорости на 32-битных системах ответ мог возвращаться не целиком;Доставляет, что раньше были распространены баги с распространением 64-разрядных систем у пользователей, а теперь с практически отсутствием 32-разрядных систем у разработчиков.
>>Исправлена ошибка из-за которой при использовании директивы limit_rate с большими значениями скорости на 32-битных системах ответ мог возвращаться не целиком;
> Доставляет, что раньше были распространены баги с распространением 64-разрядных систем
> у пользователей, а теперь с практически отсутствием 32-разрядных систем у разработчиков.Наверное мало где большой limit_rate у 32битных систем.
интересно они CGI впилят все же когда нибудь или нет?
Нет.
А зачем он там внутри, есть fcgiwrap
это геморрой на ровном месте. вместо того чтобы просто запустить мой CGI
> это геморрой на ровном месте. вместо того чтобы просто запустить мой CGIЛегкий и быстрый сервер и CGI - взаимоисключающие параграфы. Если вас интересует CGI, вам априори класть на скорость работы этого барахла и нагрузку на сервер. Нафига вам тогда нжинкс, собственно?
на этапе разработки чистый CGI удобней. удобно написать CGI прототип потом уже прикрутить FastCGI. я же не предлагаю выпилить FastCGI, я предлагаю впилить CGI. В мануале можно специально оговорить что это не подходит для высоких нагрузок.
> на этапе разработки чистый CGI удобней. удобно написать CGI прототипЗнаем мы таких "разработчиков", которым на этом этапе разработки удобно флудить на опеннетах, вместо поставить - на этом этапе разработки! - апач, вебрик или кого бы там там ни. Сами такие! //Минус разработка.
вот про то и речь что нафига мне апач если все одно потом будет и fastcgi и nginx?
> потом будет и fastcgi и nginx?Ну так пишите сразу под фасту и не выделывайтесь. Самолет хорошо получается если его сразу делать как самолет. А если его делать как апгрейд дизайна "запорожец" - задолбаетесь потом с тем что у него аэродинамика галимая.
> на этапе разработки чистый CGI удобней.Удобнее чем ... что? Например FastCGI - это совершенно иной протокол с совершенно иной логикой работы. Поэтому только не надо врать что вы можете написать приложение как CGI и потом быстро переделать его в что-то иное. Придется всю логику перекраивать. На вообще фундаментальном уровне. С "обслужили 1 запрос и умерли" до "сервер приложений".
> удобно написать CGI прототип потом уже прикрутить FastCGI.
Интересно, каким боком? Учитывая что это совсем разные протоколы с разной логикой работы. Не совсем понимаю как вы "прикручиваете" - это надо всю логику менять. Вы переписываете полпрограммы?
> я же не предлагаю выпилить FastCGI, я предлагаю впилить CGI.
> В мануале можно специально оговорить что это не подходит для высоких нагрузок.Думаю что у авторов нжинкса хватит мозгов не заниматься этой фигней. Она просто не укладывается в их концепции. Машины состояний хорошо работают когда их никто надолго не клинит. А указанное не только клинит надолго, но и заблочит обслуживание остальных запросов. В свете таких свойств - нафига вам вообще нжинкс, если он будет в результате работать не лучше префорка апачевского?
>Придется всю логику перекраивать. На вообще фундаментальном уровне.Кроме гомерического смеха это ничего не вызывает. Знаете у меня вот совершенно нет проблем создавать прототип на CGI и потом превращать его в полноценный FastCGI. Но поскольку nginx CGI не умеет приходится извращаться. Если они впилят эту возможность извращаться не нужно будет и мир станет лучше вот и все.
> на этапе разработки чистый CGI удобней. удобно написать CGI прототип потом уже
> прикрутить FastCGI. я же не предлагаю выпилить FastCGI, я предлагаю впилить
> CGI. В мануале можно специально оговорить что это не подходит для
> высоких нагрузок.Вы там что, на Си пишете? Осильте уже Django и подобные, как и во всех нормальных веб-фреймворках, там есть встроенный http сервер для разработки из коробки, одной командой запускается.
> Вы там что, на Си пишете?Я прототип хочу писать на чем угодно. И CGI это позволяет - хоть на bash. И это хорошо.
> это геморрой
> мой CGIТак! И subj тут не при чём. //Да, тролить-флудить само собой.
> это геморрой на ровном месте. вместо того чтобы просто запустить мой CGIИ ждать, пока он запустится?
Осильте написать fastcgi wrapper для вашего CGI.
> Осильте написать fastcgi wrapper для вашего CGI.Или хотя-бы готовый взять. Их есть. Только это апгрейд запорожца в самолет путем обработки напильником.
> А зачем он там внутри, есть fcgiwrapне говоря о том что это сторонняя тулза которой нет в пакете с nginx
> не говоря о том что это сторонняя тулза которой нет в пакете с nginxПотому что никто не собирается делать из ваших узкоспециализированных закидонов себе проблему. Это так сложно осознать?
> интересно они CGI впилят все же когда нибудь или нет?Никогда. И правильно делают.
>> интересно они CGI впилят все же когда нибудь или нет?
> Никогда. И правильно делают.Для вящей безопасности. CGI только ленивый не ломал.
> Для вящей безопасности. CGI только ленивый не ломал.Самому по себе CGI поводов ломаться не больше чем чему-то еще. А вот скорость у него мерзостная и любой умник может положить сервак просто сделав много запросов к оному. Далее сервак наделает зиллионы форков и тихо загнется, вплоть до выжирания всех ресурсов операционки под ноль. Ну или у хорошего админа упрется в лимиты и просто тихонько забьет на обслуживание легитимных клиентов.
Для корректной обработки CGI необходимо, чтобы Web-сервер умел делать fork()/exec() на каждый реквест страницы.
Nginx этого не будет уметь делать _никогда_.
Сначала матчасть почитайте, тогда поймёте почему в nginx никогда не будет CGI.
Если совсем коротко - nginx это FSM (КА по-русски), а не multithreaded как апач. Потому он и быстр и не прожорлив. По тому-же Сысоев всегда был против логирования в сислог. Нужен CGI - используйте врапперы или апач, не мешайте nginx работать.
это вы матчасть почитайте апач делает форки а не треды. я прекрасно умею работать как с CGI так и с FastCGI. "nginx был бы удобней если в нем была бы встроенная возможность запускать CGI" это ровно то что я хотел сказать. то что FastCGI быстрее я как бы знаю