LINUX.ORG.RU

Вышел nginx 1.7.1

 


2

2

Вышел новый релиз основной ветки HTTP-сервера nginx 1.7.1. Основным улучшением является перенаправления в syslog логов, настраиваемых через директивы «error_log» и «access_log». Были добавлены переменные «$upstream_cookie_{имя}» и «$ssl_client_fingerprint».

Напомню, что по последним данным доля nginx среди http-серверов составляет 23.5%, а apache - 56.5%.

>>> Changelog

★★★★★

Проверено: Shaman007 ()

Напомню, что по последним данным доля nginx среди http-серверов составляет 23.5%, а apache - 56.5%.

OMFG. Ну запишите уже на папять. nginx - не замена apache. У них абсолютно разные области применения

nginx работает как reverse proxy, и он жёстко заточен под эту область. apache работает за ним, как backend ; у apache богатые возможности, он универсален.

Да, apache можно поставить в качестве reverse proxy. Но работать он будет на порядки медленне nginx

Да, к nginx'у можно прикрутить fcgid, но никакого смысла в этом нет, разве что из мазохизма

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

у rsyslog есть надёжная доставка

что значит надежная? не по udp? если по tcp, то тяжелый лог забьет тебе всю сетку, при том, что писаться на удаленный хост скорее всего будет не успевать.

я не проверял сколько теряется по udp, но предполагаю что сильно зависит от нагрузки и возможностей сети

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

даже если что то теряется

тут уже зависит насколько тебе вобще нужен и важен лог

я вообще не понимаю этого ограничения

ограничение в том, что люди не хотят применять ненадежную технологию. то есть, если они это добавляют, то заявляют, что функциональность работает. а по факту работает она плохо, видимо поэтому у разработчиков нет желание делать свой продукт плохим, только из-за того, что на данный момент нет хороших технологий для желательного функционала. в итоге они написали полностью свой udp механизм для передачи данных в syslog, чтобы хоть как-то взять ответственность за некорректную работу логирования.

autonomous ★★★★ ()

Доля http серверов как-то странно считалась, я думаю.

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

Да, к nginx'у можно прикрутить fcgid, но никакого смысла в этом нет, разве что из мазохизма

nginx давно уже все умеет. для php есть php-fpm, для перла можешь пользовать apache mod_perl или uwsgi, для питона uwsgi. все работает как часы. так что вылезай уже из криокамеры.

apache работает за ним, как backend

уже не актуально лет 5 как

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

syslog работает по udp и теряет тем больше инфы, чем быстрее пишется лог

rsyslog умеет tcp. Т.е. сценарий такой: нжынкс пихает пачки строк в сокет локальному демону, тот валит полученное в локальный файл и еще временами отгружает буфер на центральный логсервер.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от autonomous

«Гвозди уже больше 500 лет можно забивать микроскопом. Вылезай уже из криокамеры. Молоток не актуален»

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

У них абсолютно разные области применения

Да хрен там разные.

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

rsyslog умеет tcp.

Вот кстати оффтопик. Среди syslog'ов есть кто-нибудь, кто может пережить длительное отсутствие канала связи ( заведомо больше tcp connect timeout ), и потом дослать все накопленные логи?

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

что значит надежная? не по udp?

http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html

утверждает что tcp - industry-standard. плюс к тому там какая то третья штука, REPL называется, которая обеспечивает ещё более надёжную доставку чем обычное plain-tcp.

если по tcp, то тяжелый лог забьет тебе всю сетку,

мне просто любопытно лог что всегда тяжелый? У меня не тяжёлый если что, tcp его вполне держит, сетку не забивает.

неужели там под штуку мегабитов лог пишется у тебя? ну если так, я сочувтствую. мне эта проблема не ведома пока что.

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

десяток-другой мегабит (оценка сверху)?? не успевать?? ого, батенька. даже если сотка - успеет вполне. С другой стороны, как это так - на локальное устройство будет успевать писать а на удалённое нет (при том что рпоблема не в сети). Что у вас там за конфигурация такая?

У вас наверное зверские какие-то логи, может вам оно и так. Ну не пользуйтесь тогда, никто ж не неволит. А мне вот сподручно и без лишнего гемора. nginx великолепен откровенно говоря. Но этот вечный гемор с пачтами для лога меня уже достал немного. При том что Сысоева ещё с зари времён просили добавить эту фичу, а он упирался.

ограничение в том, что люди не хотят применять ненадежную технологию. то есть, если они это добавляют, то заявляют, что функциональность работает. а по факту работает она плохо, видимо поэтому у разработчиков нет желание делать свой продукт плохим, только из-за того, что на данный момент нет хороших технологий для желательного функционала. в итоге они написали полностью свой udp механизм для передачи данных в syslog, чтобы хоть как-то взять ответственность за некорректную работу логирования.

ну я рад. правда я боюсь что это их собственное поделие будет подглюкивать первое время, но это уж издержки... я думаю сфера применения даже «плохого» логгирования очень и очень широка. И люди которые его применяют отдают себе отчёт в том что делают. А те кто не отдают и так и так не понимают. Считал и считаю решение «не писать в сислог» откровенно плохим и с технической и с социальной т.з.

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

Вот кстати оффтопик. Среди syslog'ов есть кто-нибудь, кто может пережить длительное отсутствие канала связи ( заведомо больше tcp connect timeout ), и потом дослать все накопленные логи?

по моему rsyslog зависит только от буфера. в смысле если буфер достаточный - дошлёт. но не уверен, надо глядеть документацию.

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

А вот эта гордая штука в связке с таким же input module'ом подобного не предоставляет? Вроде как по названию должно.
В любом случае, чисто теоретически можно представить ситуацию, когда при отправке неизбежно протеряется часть логов: например, получатель недоступен, а из-под отправителя кусок логфайла выдрало каким-нибудь logrotate'ом. Не в памяти ж ему весь недопосланный буфер держать.
Хотя...

thesis ★★★★★ ()

В общем, всё это очень здорово, но почему для последней федоры, этого ледокола, бороздящего опенсорцное дистрибутивное болото, этого инкубатора продуктов с необрезанной пуповиной, этого отстойника передовых технологий -
короче, какого рожна в федориных репах до сих пор валяется давно заплесневелый 1.4.7?

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

М.б. потому, что есть официальный репозиторий?

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

Они для федоры не собирают, если ты про офрепу nginx.
Если есть какая-то федорина репа, то я про нее не знаю, нашел только какого-то COPR'одела, который 1.7.1 пока не собирал.

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

Не в памяти ж ему весь недопосланный буфер держать.

rsyslog держит в буфере на диске.

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

В федору не встанет nginx, собранный для rhel или centos?

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

Спасибо, на нём и остановился. В syslog-ng repl только в платной версии PE 4.2

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

рад что подсобил.

В syslog-ng repl только в платной версии PE 4.2

как у них там всё жестко...

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

Страшнее что он встанет и будет работать как говно. Уж я лучше сам, из родного spec'а... Но вопроса же это не снимает.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от Lincor

насколько он быстрее апача

если важна только скорость, используй khttpd - он умеет еще меньше, чем nginx, зато еще быстрее.

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

Скорость развития у него, конечно, не ахти

Они просто из принципа не запиливают фичи чтобы оставаться light (в багтрекере по этой же причине давно отказались запиливать поддержку htaccess).

Кстати, где-то (может на opennet) видел результаты теста, по которым выходило что лайти на отдаче статики работает чуть быстрее nginx (но незначительно).

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

Да, к nginx'у можно прикрутить fcgid, но никакого смысла в этом нет, разве что из мазохизма

А нафига использовать монструозный Апач, если тебе нужно только раздавать статику и обеспечить работу Django, например? Я вообще Lighttpd использую, например.

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

Централизированные лог коллекторы например. Это же удобно иметь все логи на одной машине

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

Ога, и когда эта машина ложится, то у тебя ложится всё. Это конечно же очень «удобно». В современном мире принято писать лог в файл и отправлять его в _распределенное_ хранилище внешними утилитами.

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

ничего странного, это факт который никто не учитывал, именно в этой связке счастье пока

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

кстати так и не получилось reverse proxy с ftp://ftp... может у кого то вышло... поделитесь люди!

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

действительно легкий по сравнению с апачем сервер, умеет подмену заголовка, но с zend framework что то странное с ним

Frost ★★ ()

А я на своей личной VPS-ке поставил Hiawatha. А что, память не жрет, конфиг простой, Roundcube, Tiny Tiny RSS и веб-прокси работают отлично.

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

одно другому не мешает. не путайте мониторинг логов и их архивацию.

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

И то и то можно делать одним инструментом.

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

«Гвозди уже больше 500 лет можно забивать микроскопом. Вылезай уже из криокамеры. Молоток не актуален»

дада, никаких новых схем, работаем только так как завещал гуру с первого места работы

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

вот расскажи, зачем мне нужен апач, если у меня приложение на питоне?

autonomous ★★★★ ()
Последнее исправление: autonomous (всего исправлений: 1)
Ответ на: комментарий от SI

Что, код который работал и работал, резко стал плохим?

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

nginx сам умеет кешировать, зачем еще squid добавлять?

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

В Арче до сих пор 1.6.0

потому что 1.6.* это стейбл, а 1.7.* это дев

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

Они просто из принципа не запиливают фичи чтобы оставаться light

Да я про то, что в багтрекере хренова куча незакрытых багов, жор памяти при передаче большого количества данных через лайти в режиме прокси/[Fast]CGI вообще помечен как wontfix, официально находящиеся в разработке ветки 1.5 и 2.x уже фиг-знает-сколько зарелизить не могут. Он, конечно, совсем неплох, сам им пользуюсь, но перечисленные вещи как-то удручают.

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

лог что всегда тяжелый? У меня не тяжёлый если что, tcp его вполне держит, сетку не забивает.

Ты не на объём данных смотри, а на кол-во пакетов. По udp один пакет уйдет, а по tcp пять — syn,syn-ack,data,ack,fin. Каждый входящий пакет — прерывание от сетевухи.

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

пошёл почитал, удостоверился, ты не прав.

сначала идёт трёхстороннее рукопожатие, это три пакета.

потом уже непосредственно передача данных - это один пакет с данными от отправителя к получателю + 1 пакет ACK от получателя к отправителю.

Потом завершение сессии - 3 пакета.

Т.е. там там где у udp один пакет получается, по tcp выходит совсем не пять, а два. Причём эти два не в одну сторону, а в разные. Т.е. нагрузка хоть и растёт, но численно можно грубо предполагать что примерно вдвое по сравнению с юдипи. А может быть и значительно меньше из за того что разные направления передачи (хотя может быть и больше, надо разбирать более конкретно).

Кроме того я не очень понимаю как там всё это работает с прерываниями. Может быть так как ты говоришь - через прерывания, а может там что то вроде прямого доступа к памяти, - я имею ввиду механизм похожий на dma у дисков, - ты знаешь как работает?

AndreyKl ★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 3)
Ответ на: комментарий от AndreyKl

я и не имел ввиду что они все в одну сторону.

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

Хорошо, со сторонами я может быть неверно тебя понял. Но не менее важно чем стороны то обстоятельство что пакетов 2, а не 5. Так же я думаю важно что там все кто только может (включая сетевухи) давным давно используют dma, а не прерывания, как ты заявил.

То есть твои прикидки в корне не верны, даже если брать очень грубо.

AndreyKl ★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.