Вышел NGinx версии 0.4.14

Вообще-то, под ядром линуха 2.6.х что поток, что процесс -- все примерно одинаково, за исключением отсутствия шаринга виртуальной памяти.

Не знаю, где он там еще стоит, но то, что nginx - явный лидер среди хостеров порносайтов - факт.

> кто вам сказал что тред много быстрее форка
Создание треда НАМНОГО быстрее fork.
Напиши простую прогу на pthread и посмотри сам)).
В частности потому что при fork создаются новые таблицы страниц,
дескрипроров и т.д. А в случае с тредом это
все используется совместно. В добавок нужно модифицировать
таблицу страниц у родителя, что-бы отлавливать изменения родителем
своих страниц. Плюс к этому после форка каждое первое обра-
щение на запись к странице памяти(4k) приводит к созданию
ее копии и модиф. одной из таблиц страниц. Так что на форк
затраты таки велики. Другой разговор что к современному аппачу
это никакого отношения не имеет т.к. он умеет треды.

>Не знаю, где он там еще стоит, но то, что nginx - явный лидер среди хостеров порносайтов - факт.

откуда дровишки? ;)

>> А в случае с тредом это все используется совместно.

про стек забыл...

> про стек забыл...
Ни про что я не забыл )).
Я вполне могу из одного треда залезть в стек другого.
Стек у треда это не память а только регистр SP.
Значения SP,конечно, отличаются но памать используется
из одного адресного пространства.

Инфа к размышлению:

1. mod_php ДАВНО умеет работать с многопоточным апачем.
2. lighttpd является не многопоточным, а мультиплексорным. И nginx по-моему тоже. Мультиплексор - это один процесс и один поток, просто nginx вроде бы несколько мультиплексоров форкает, но тут могу врать.
3. fork в апаче делается далеко не на каждый request. У каждого Child-а есть понятие MaxRequestsPerChild и parent-процесс форкает новых детей только если либо не хватает текущиего кол-ва детей на обработку текущей нагрузки, но не более MaxClients, либо если у какого-то Child'а закончился жизненный цикл.

P.S. про мультиплексор - man poll

о чём спор? nginx может использовать треды, но не обязан. обычно он запускает несколько рабочих процессов, которые обслуживают все запросы, не создавая новых процессов или тредов.

зачем нужен lighthttpd, когда есть nginx -- вот в чём вопрос...

Кстати, у nginx'а давно была проблема с очень маленьким таймаутом при коннекте к backend'у или типа того. Вобщем там, где например squid (кстати, тоже мультиплексор) немного ждет и таки выдает страницу с backend'а, nginx с присущей ему скоростью фигачит тоннами 502 Gateway timeout. А возникает такое свинство например при рестарте/релоаде backend апача, когда под апачем сидит несколько тыс. вирт. хостов. Надеюсь со временем Сысоев это пофиксит.

> Те страницы которые не изменяются - не дублируются.

А что произойдет, если по всему коду много static методов/функций и переменных? Вопрос не праздный - я хочу это выяснить для себя. Если рассказывать долго, то ткните меня носом в мануальчик. С большим удовольствием прочту. Заранее спасибо.

Сравнивать производительность по времени создания треда или процесса некорректно, ибо апач не работает в стиле fork per request. Все процессы он создает заранее. Более того, как уже сказали, один процесс обычно обрабатывает несколько запросов. С тредами, вроде, то же самое.

>>Я, может, туплю... Но вообще с трудом такое представляю. Ведь, собственно, у защищенных систем первейшая задача - не допускать "чужие" процессы лезть в память текущего процесса.

>Страницы кода и данный разделены, копия данных уникальна для каждого процесса, а код, естественно реентабельный.

и врешь-то ты все ;-) данные тоже шарятся, но при записи - страница копируется. copy-on-write то бишь.

P.S. а реентерабельность тут даже рядом не лежала ;-)))))))) или ты серьезно считаешь что apache весь реентерабельный?

ну, вы, народ, даете. более безграмотной дискуссии я еще не видел. Во-первых, nginx использует неблокируемое IO а не треды, хотя какая-то поддержка тоже есть. Во-вторых, отлично распаралеливается на несколько процессоров,хоть nginx это и не к чему, курите в сторону worker_processes. В третьих, у апача с mod_php не будет "11.5 метров общих из 12" ни с prefork ни с другим mpm, особенно на больших и тяжелых сайтах типа битрикса или еще чего похуже(вообще, апачи по 30метров не редкость если скрипты кривые), можете проверить. В четвертых, если юзер начнет с апача у которого maxclient 100 качать большой файл в 100 потоков то, пока он не скачает, никто от сервера ничего не получит, все чайлды будут "заняты" отдачей контента. В пятых, нагруженным серверам maxclient 100 мало, нужно больше 250. А с таким кол-вом апачей гига оперативы уже мало, сервер лезет в своп и несчадно тормозит. Кроме того, из-за частых переключений контекста и других причин, 20 апачей обработают 1000 запросов быстрее чем 200 апачей и при этом отожрут меньше памяти(за счет сериализации запросов). Так же напомню что apache13 не умеет sendfile.

ошибка 504 значит что бэкенд не отвечает. Почему-то все думают что виноват nginx. А если 404 тоже nginx виноват?

Как видите о серверах вы знаете очень мало. Дальше продолжать не буду, курите доки.

PS юзал lighttpd и nginx на серверах. Оба не идеальны, оба имели критичные глюки, но в целом особой разницы между ними не разглядел.

> Я, может, туплю... Но вообще с трудом такое представляю. Ведь, собственно, у защищенных систем первейшая задача - не допускать "чужие" процессы лезть в память текущего процесса.

Т.е. кто такие pagetables и что такое copy-on-write ты совсем не в курсе? А ну-ка марш учить матчасть!

> Страницы кода и данный разделены, копия данных уникальна для каждого процесса, а код, естественно реентабельный.

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

Еще бывает "position independance" - это когда куску исполняемого кода без разницы (ну, с точностью до выравнивания) по какому адресу его загрузили (ну, грубо - все джампы относительные или через lookup-table). Это нужно в .so-шках, и регулируется компилятором (-fPIC).

А еще бывают copy-on-write страницы, pagetables и mmap, который умеет отображать одну физическую страницу, связанную с одним куском файла (в данном случае - бинаря) на диске в разные (хотя в данном случае - одинаковые) виртуальные адреса в разных процессах - и именно эти механизмы обеспечивают сохранение памяти на форке. При это код может быть _не_ реентрабельным и _не_ PI.

> Так что на форк затраты таки велики. Другой разговор что к современному аппачу это никакого отношения не имеет т.к. он умеет треды.

Учтя, что падефолту maxrequestsperchild 10000, апач форкается достаточно редко.

Форк-процессы в апаче форкаются от рутового апача который юзеров не обслуживает. Это значит что воркеры между собой имеют только ту часть общую которая есть у рутового апача. Все остальное что у них есть и что стало после инициализации модулей оно не shared. Если апач жирный, с кучей всяких жирных модулей(mod_perl, mod_php), то память это скушает будь здоров, особенно если люди не скупяться выделять память в своих скриптах. Если не скупятся и паралельно работает даже 100 апачей то пипец сервачку, его спасет только сериализация запросов через проксю и ограничение кол-ва бэкендов.

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

а ты думаешь php больше памяти под себя не выделяет? Посмотри ps awwux| grep ht, там сразу видно какой апач рутовый а какой нет. Запусти ab(apache bench) в 200 одновременных потоков и посмотри скока памяти в системе после этого останется.

Это понятно, но зачем ты говорил, что общее у них только то, что от общего предка? Это неправда, и я ответил конкретно на это.

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

> ну, вы, народ, даете. более безграмотной дискуссии я еще не видел. Во-первых, nginx использует неблокируемое IO а не треды, хотя какая-то поддержка тоже есть.

> поддержка aio в ngix пока еще в зачаточном состоянии

> Кроме того, из-за частых переключений контекста и других причин, 20 апачей обработают 1000 запросов быстрее чем 200 апачей и при этом отожрут меньше памяти(за счет сериализации запросов).

не факт. если криворукие студенты наклепали "текучих" скриптов, то после 10 последовательных запросов, обработанных одним процессом (mod_php) память может и закончится быстрее.

> ошибка 504 значит что бэкенд не отвечает

не факт. это может означать, что у ngix "сорвало крышу" и он не может или не пытается переустановить соедиение

> Почему-то все думают что виноват nginx. А если 404 тоже nginx виноват?

наивный чукотский парень :) это может означать все, что угодно.

> Как видите о серверах вы знаете очень мало

хотелось бы знать больше, да времени и сил на все не хватит

> PS юзал lighttpd и nginx на серверах. Оба не идеальны, оба имели критичные глюки, но в целом особой разницы между ними не разглядел.

согласен с тем, что оба не идеальны, но... lighttpd не пытается изображать из себя pop3/imap proxy, зато умеет, помимо fastcgi, scgi и x-send-file. я бы сказал, что ngix очень сильно заточен под нужды rambler со всеми вытекающими последствиями.

> где вы там 12 мегабайт нашли? 160К не хотите? ;)))

Во-первых не я говорил про 12 мегабайт, если внимательно отследить тред. Во-вторых, говорю же, всё зависит от проекта. Есть у меня проекты, которые требуют столько модулей, и такие perl скрипты грузят, что один ребенок может и 30 и 50 мегабайт схавать.

>Проникнись: "Перед каждым релизом я собираю nginx несколькими компиляторами — gcc, icc, msvc, bcc и openwatcom

Проникся ;), а что openwatcom уже под Linux есть?

А при чём тут Linux? nginx не только под Linux работает.

Я просто хотел что-то хорошее услышать: OS/2 и Win не очень интересуют

>1. mod_php ДАВНО умеет работать с многопоточным апачем.

Это н еработа, это глюкалово.

> 2. lighttpd является не многопоточным, а мультиплексорным. И nginx по-моему тоже. Мультиплексор - это один процесс и один поток, просто nginx вроде бы несколько мультиплексоров форкает, но тут могу врать.

Да. lighttpd тоже кстати может несколько.

>> Особенный респект за то, что к версии 0.4.13 он наконец доэволюционировал до того, чтобы системный pcre цеплять, а не требовать для сборки исходники.
Он НИКОГДА не требовал для этого исходники. толкьо заголовки. НО - может собраться и статически с другим pcre если будут исходники. читайте документацию

>> согласен с тем, что оба не идеальны, но... lighttpd не пытается изображать из себя pop3/imap proxy, зато умеет, помимо fastcgi, scgi и x-send-file. я бы сказал, что ngix очень сильно заточен под нужды rambler со всеми вытекающими последствиями.

Извините, но много ли видели случаев когда нужен scgi ?
Вообще nginx предполагает что если данные не статические и не fcgi - то стоит apache бэкенд с которого контент и проксируется.
x-send-file: читайте про X-Accel-Redirect
lighttpd кстати умеет отдавать контент из memcached ?

>> ошибка 504 значит что бэкенд не отвечает
>> не факт. это может означать, что у ngix "сорвало крышу" и он не может или не пытается переустановить соедиение
То есть сорвало крышу ? Если бакенд не ответил - то зачем пробовать установить соединение ещё раз ? Если речь идёт о 502 - то можно увеличить время ожидания от бэкенжа.

но вообще дикость - сравнивать apache с naginx. у них соверщенно разные задачи и способы их достижения. взять хотя бы классическую связку nginx фронтенд + apache бакенд, когда толкьо за счёт проксирования освобождается куча памяти и процессорного времени которое раньше отъедал apache.

>> То есть, оно для однопроцессорных машин. Очень мило.
гыгы. процессов принимающих и обрабаытвающих соединения может быть больше одного. скажу больше
для каждого воркера можно явно указать на каких процессорах он может работать, а на каких - нет.

но вообще в случае c nginx схема естесвенная дла апача не работатет - обычно раньше заканчиваются возможности дисковой подсистемы чем сам nginx начинает требовать наличия больше чем одного процессора

>> Так что на форк затраты таки велики. Другой разговор что к современному аппачу это никакого отношения не имеет т.к. он умеет треды.
>Учтя, что падефолту maxrequestsperchild 10000, апач форкается достаточно редко.
гдеж вы видели такой дефолт ? на 256 ли часом зашито #define'ом в код ?
про память промолчим конечно, от греха. а переключение контекста на каждый запрос ?

>>1. mod_php ДАВНО умеет работать с многопоточным апачем.
>Это н еработа, это глюкалово.
ну нет. сам то он нормалньо работает. то что часть модулей работает глюкаво, это не повод гнать на mod_php

> А что произойдет, если по всему коду много static методов/функций и переменных? Вопрос не праздный - я хочу это выяснить для себя. Если рассказывать долго, то ткните меня носом в мануальчик. С большим удовольствием прочту. Заранее спасибо.

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

>>Проникнись: "Перед каждым релизом я собираю nginx несколькими компиляторами — gcc, icc, msvc, bcc и openwatcom

>Проникся ;), а что openwatcom уже под Linux есть?

То есть наличие msvc под Linux вопросов не вызвало? ;)

>> не факт. это может означать, что у ngix "сорвало крышу" и он не может или не пытается переустановить соедиение

Под freebsd 4.8 действительно он работал как-то неадекватно, под более свежими осями глюков кроме сигфолтов воркеров не видел. Более-менее свежий nginx уже избавлен от этого глюка. Смотри nginx-error.log, там будет написано от чего проблемы.

Народ, а объясните, пожалуйста, - как правильно Perl-скрипты под FastCGI запускать? (Чтобы не писать на Perl сервер, форкающий клиентов, если такое возможно. Прошу прощения, в теме плаваю.) Или ткните носом в статейку по теме.

>То есть наличие msvc под Linux вопросов не вызвало? ;)

Наличие msvc замечено не было т.к. не очень интересовало ;)

>Наличие msvc замечено не было т.к. не очень интересовало ;)

OW opensource. под линь вроде бы собирается, но код под него генерировать еще не научился

nginx какой то ... lhttpd какой то :) лажа все это. 16 CPU's,44Gb RAM,4Tbytes,1200вирт хостов,apache. HDD и ПНХ этот nginx. а в случае чего "самая красная на свете кнопка поможет" :)

В качестве эксперимента зашёл на упомянутый выше http://nnm.ru и увидел вот что - 504 Gateway Time-out nginx/0.3.33

> Извините, но много ли видели случаев когда нужен scgi ?

го-о-раздо больше, чем тех, когда нужен pop3/imap proxy на web-сервере. scgi - аналог fastcgi, но боллее простой в реализации

> lighttpd кстати умеет отдавать контент из memcached ?

механизмы кэширования в lighttpd гораздо более гибкие, чем в ngix.

4aosiniao: backend курит.

> 4aosiniao: backend курит.

Ну так надо его перезапустить, и не высаживаться. :) Почему-то у меня сформировалась стойкая ассоциация "502 Gateway Timeout" <-> "NGinx". :P

s/502/504/ =)

Бекэнд перезапустить? Ну напиши держателям nnm.ru

Не было б nginx'а - ты б и 504 не увидел.

> Бекэнд перезапустить? Ну напиши держателям nnm.ru

Ну, почему-то Lighttpd справляется с перезапуском подвисшего FastCGI-сервера без посторонней помощи. :) Неужели NGinx этого не умеет?

умеет, надо тока взять скрипты из lighttpd

ero-sennin: ты уверен, что аппсервер там реализован как fcgi? А не как apache+mod_php (если там PHP), например?

Перезапуск - это не к nginx'у, а к держателям nnm. Если они такой ситуации не предусмотрели, при чём тут nginx?

anonymous (*) (29.11.2006 16:50:20)

>> Извините, но много ли видели случаев когда нужен scgi ?
> го-о-раздо больше, чем тех, когда нужен pop3/imap proxy на web-сервере. scgi - аналог fastcgi, но боллее простой в реализации
возмодно вы просто не сталкивались со случаями когда pop3/imap прокси необходим - так как бакенды живут на разных машинах.
что такое scgi - я в курсе. почти всё что умеет scgi умеет и fastcgi котороый по факту более распространнён.

>> lighttpd кстати умеет отдавать контент из memcached ?
>механизмы кэширования в lighttpd гораздо более гибкие, чем в ngix.
замечу что в nginx вообще нет механизм в кеширования. не уверен что это вообще дело веб сервера заниматься кешированием.

что вы вообще пытаетесь доказать ? то что nginx чего то не умеет ? да, наверное многого - смотря с чем сравнивать. но то что он умеет более чем достаточно для решения задач того класса где он потенциально применим.

кстати - о чём никто не упомянул. в nginx есть встроенный перл.

> в nginx есть встроенный перл.

Даёшь встроенный тетрис на встроенном перле!

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

Однако, лично я, так и предпочитаю до сих пор lighttpd... Вот освою ещё CML - вообще будет супер :D И кто сказал, что веб-сервер кешированием не должен заниматься?