Вышел nginx 1.7.1

умеет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты не прав и упорствуешь.

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

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

rsyslog умеет tcp.

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

сам отвечу: да, есть

http://en.wikipedia.org/wiki/Reliable_Event_Logging_Protocol

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А, тогда вообще замечательно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

syn,syn-ack,data,ack,fin

я что то сейчас усомнился

В чем усомнился?

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

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

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

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

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

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

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

Syslog-Ng

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

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

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

прерывания и как с ними быть? если система тормозит. (комментарий)

спасибо, просветился