lighttpd-1.4.10

nginx

Спасибо за хорошую новость!

Только, вообще-то, не max-extensions, а map-extensions, и про fastcgi.server я не врубился: а разве оно не работало? 8-O

Первоисточник тут: http://www.lighttpd.net/download/NEWS.html

> nginx

А не могли бы вы аргументированно описать преимущества nginx перед lighttpd? =)

Оригинальная новость была отредактирована, так что ответсвенность за дальнейшую формулировку несут модераторы ;)

А почему столько "должно"? Автор не уверен в работоспособности?

>рапределение нагрузки под fastcgi должно работать, как предпологается

Должно быть "раСпределение" и "предполАгается".

Иногда возникает впечатление, что ЛОР - это место где лингвисты поправляют безграмотных. Можно хоть вебсервис создавать, который будет постить проблемное слово в любой тред, ждать ответа, и высылать поправленные версии.

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

А можно узнать у уважаемого анонимуса чем ngnix или даже тот же loghthttpd лучше допустим apache2 с mpm worker ?
.htaccess-файлы поддерживаются ?
Аналог mod_rewrite есть ? Синтаксис rewrite такой же как у апача ? mod_actions аналог есть ? Синтаксис такой же ? В чем сила, брат :) ?

nginx хорош тем, что делается профессионалом, работающим в Рамблере, так что релизы проходят обкатку на реально крупных сайтах.

ананимусу, требующему указать отличия nginx/lighttpd от апача - срочно самообразовываться про мультиплексный (nginx/lighttpd) VS мультитредный/мультипроцессный (apache) методы обработки соединений.

Я так понимаю что ключевое слово здесь _профессионалом_, то есть одним каким-то человеком, пусть даже работающем в рамблере. Нисколько не умоляю достоинства г-на Сысоева, но до апача ngnix'у еще очень далеко, а уж то, что хостинговые компании врядли перейдут на него как на основной веб-сервер, а не только будут использовать его в качестве frontend прокси (что кстати и squid неплохо умеет), это я думаю совершенно точно.

Впрочем для индивидуальных сайтов ngnix самое то, FastCGI есть, больше по сути ничего не надо. Тем более что даже пых пых в apache2 + mpm worker + fastcgi работает быстрее всеми любимого mod_php c mpm prefork.

>Иногда возникает впечатление, что ЛОР - это место где лингвисты поправляют безграмотных

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

В любом случае, прошу прощения если обидел.

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

Дык в для этого случая сабж слишком тяжёлый ;). khttpd на такой задаче точно всех порвaл бы. Или его совсем бросили с тех пор как вынесли из ванильного ядра?

> Впрочем для индивидуальных сайтов ngnix самое то, FastCGI есть, больше по сути ничего не надо. Тем более что даже пых пых в apache2 + mpm worker + fastcgi работает быстрее всеми любимого mod_php c mpm prefork.

О! Где посмотреть тесты/обсуждение? Мне скоро актуально будет, планирую на perl писать прототип одной системы, и думал не отказаться ли от apache/nginx вообще, реализовав обработку http самостоятельно (мультиплексирование http на perl я уже делал).

К слову, khttpd давно уже не нужен, и даже не быстрее TuX или X15. При том он очень сильно "не быстрее", раз в 5-8. И у апача выигрывал совсем не много и очень давно. Так что его вынесли просто за ненадобностью.

> Дык в для этого случая сабж слишком тяжёлый ;). khttpd на такой задаче точно всех порвaл бы.

Это уже для маньяков. :) А lighttpd мне вполне подошёл, ибо у меня на домашнем сайте три файла...

> Где посмотреть тесты/обсуждение?

К сожалению видимо нигде. Я тестировал сам в прошедшие выходные, 50 виртуальных хостов, сервер dual xeon, 2Gb памяти, тест делался прогой siege, грузилась простенькая страничка на php и картинка, чтобы была динамика + статика. Оказалось что apache2 + mpm worker + php-fastcgi отдает такую вот страничку (там по сути просто phpinfo() + uid/gid печатался) и картинку в 1 килобайт быстрее примерно на 10% чем тот же apache 2 + mpm prefork + mod_php4. Siege запускалась на том же сервере, то есть передачи по сети небыло. ТО есть видимо остается только поверить мне наслово. Хотя, если честно, суть моего эксперимента была в том чтобы убедиться что php-fastcgi не медленее чем mod_php, но это я увидел даже если для обоих вариантов ставить apache2 с mpm prefork. Ну а worker уделывает prefork как минимум на статике, что не удивительно

>ананимусу, требующему указать отличия nginx/lighttpd от апача - срочно самообразовываться про мультиплексный (nginx/lighttpd) VS мультитредный/мультипроцессный (apache) методы обработки соединений.

Можно пояснить в двух словах, что есть мультиплексный и что есть мультитредный\мультипроцессный? какое плюсы\минусы у того и другого? что эффективнее работает на SMP-машинах?

А он поддерживает виртуал-хосты на разных портах?

>>.htaccess-файлы поддерживаются ?

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

>>Аналог mod_rewrite есть

YES ^)

>>Синтаксис rewrite такой же как у апача

Нет, но по оему наискромнейшему мнению он гораздо более гибкий бо завязан на перле

>>Синтаксис такой же

синтаксис чего? конфига? нет, совсем другой

>>В чем сила, брат :) ?

А сила, брат, в правде :)) апач если не ошибаюсь, юзает select(); в то время как сабж и nginx имеют поддержку epool && rtsignals со всеми вытекающими, да и потом, nginx нашенский, а не буржуинский ;)

> бо завязан на перле

Это как? 8-[

http://sysoev.ru/nginx/docs/install.html

--with-pcre=<путь> &#8212; задаёт путь к исходным текстам библиотеки PCRE. Дистрибутив библиотеки (версию 4.4 &#8212; 6.1) нужно взять на сайте PCRE и распаковать. Всё остальное сделают nginx'овские ./configure и make. Библиотека нужна для использования регулярных выражений в location и для модуля ngx_http_rewrite_module.

;)

PCRE - Perl Compatible Regular Expressions

Вообще-то Сысоев своим ngnix и не собирается заменять апач ни разу. Такое не декларировалось ни при проектировании, нет и сейчас в TODO. Это - frontend/сервер для раздачи статики.

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

Потому что аффтары тужатся выглядеть очень умными, но когда их ловят не элементарной неграмотности, им очень трудно сохранить мнимое достоинство.

nginx идеален для крупных и очень крупных сайтов, и не только для статики, но и для FastCGI (в т.ч. PHP), а недавно в нем появился и перловый модуль.

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

Ладно, с этим все понятно, так вобщем оно и виделось. Вопрос другой: чем он лучше squid для frontend ? Опять же тем что epool && rtsignals ?

> Нисколько не умоляю достоинства г-на Сысоева, но до апача ngnix'у еще
> очень далеко, а уж то, что хостинговые компании врядли перейдут на
> него как на основной веб-сервер, а не только будут использовать его в
> качестве frontend прокси (что кстати и squid неплохо умеет), это я
> думаю совершенно точно.

я надеюсь, у г-на Сысоева нет планов world domination, в частности - планов заставить хостинговые компании перейти на nginx ;)

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

>А сила, брат, в правде

Сила в ньютонах.

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

Или разносить нагрузку по серверам. Поскольку упереться в сеть/процессор совсем не мудрено.

Интересно было бы понять, сколько overhead при использовании apache2+perl-fastcgi в сравнении, скажем, с чистым мультиплексированием http на perl.

Ох, как я стал ленив писать код только для экспиремента... :)

народ а ктонить пробовал SHTTPS? маленький и шустрый а апаче это конечно круто если сайт темовой держит а для маленьких страниц он смирно идёт в печ

>Вообще-то Сысоев своим ngnix и не собирается заменять апач ни разу. Такое не декларировалось ни при проектировании, нет и сейчас в TODO. Это - frontend/сервер для раздачи статики.

оно HTTP/1.1 умеет? так чтобы я апач на localhost повесил? или только HTTP/1.0 ?

Использую связку Apache + lighttpd.

Вся сложная динамика - на Apache. Лёгкая динамика - на сабже.

Поклонниками ngnix (давно не следил за ним), научился он:
- Работать с автоконфигурируемыми вирт-серверами?
- mod_rewrite, mod_deflate, mod_status, mod_redirect, mod_access, mod_auth, mod_webdav? Сабж умеет ещё с дюжину mod_* :)
- ручками настраиваемые mime для заданных масок URL (не по расширениям файлов)

> я надеюсь, у г-на Сысоева нет планов world domination, в частности - планов заставить хостинговые компании перейти на nginx ;)

Он пишет, что нет. Но странное дело - ошибку в стиле 502 (кажется) в общем - перегрузка :) и подпись nginx я стал в последнее время наблюдать поразительно часто. Может уже пора изучать и ну его апач? ;-)

Я вот одного не понимаю, по вопросам лёгкости - tux не лучше будет, он, вроде, вообще, модулем в ядро встраивается?

основной минус nginx -- это не перечисленное, а отсутствие документации и исходник, в кторого можно сломать ноги. Так что разобраться в нем кроме Сысоева никому не дано...
а lighttpd хорошо, но одно добивает -- использование sendfile/sendfile64 он определяет во время компиляции _только_, так что собрав на машине с 2.6 его потом не поставишь на машину с 2.4 8((((((

вот как раз lighty -- хорошее решение для скриптов, ибо умеет fastcgi, что на нагрузках _гораздо_ лучше, чем mod_php/mod_perl/mod_python по нескольким причинам. Уж верьте мне 8)

мультипроцесс.мультитред отпочковывают новый процесс/тред на каждого клиента. Это хорошо когда обработка клиента очень долго идет, например. Плохо тем, что N процессов и даже тредов это тяжело, когда N вырастает хотя бы до сотен.
мультиплексирующий использует один процесс с select()'ом по набору дескрипторов. Хорош там, где N велико и там, где обработка одного запроса клиента быстра. Идеальный случай -- отдача статики под нагрузкой, например.

у меня статика mathopd'ом плюется. Хотя сейчас активно смотрю на lighttpd...

~ 10^7 хитов в сутки, плюс-минус пара.

>А сила, брат, в правде

//Сила в ньютонах.

В натуральных продуктах.

Насчет Ремблера ну уморили...

lighttpd используется для ряда целей на wikipedia и других очень не маленький сайтах рядом с которыми ремблер молочный козленок.

Более того lighttpd делается не одним человеком а community пользователей как и apache - хотя Jan и делает большую часть работы. Это всегда хорошо - голова хорошо а две лучше.

>Zulu *** (*) (09.02.2006 0:44:54)

thx за пояснение

Здесь есть различные тесты и сравнения с другими веб-серверами: http://www.lighttpd.net/benchmark/

P.S. если вы не увидели свой веб-сервер (например, nginx), напишите автору, чтобы он включил их в следующих тестах :)

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

> Или разносить нагрузку по серверам. Поскольку упереться в сеть/процессор совсем не мудрено.

вот то-то и оно, что упереться в CPU мультиплексирующим серверам гораздо труднее (в случае просто статики - даже и невозможно), они скорее в диск/сеть упрутся, что кстати сплошь и рядом и происходит.

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

> Но странное дело - ошибку в стиле 502 (кажется) в общем - перегрузка :) и подпись nginx я стал в последнее время наблюдать поразительно часто. Может уже пора изучать и ну его апач? ;-)

Ошибка 502 (Bad Gateway) означает, что nginx не смог вызвать fastcgi сервер. это может значить все что угодно - fastcgi процесс упал, запущено слишком мало серверов (типа уперлось в MaxClients), наконец, кривая конфигурация для какого-то location...

О, как интересно! mod_php, mod_perl, fastCGI это всё хорошо, но вот вопрос:
А есть ли какой-нибудь легковестный HTTP-server для статики имеющий возможность отдавать запросы на динамику в Servlet Container. Типа Tomcat. Есть модуль mod_jk2.

Весьма актуальный вопрос кстати.

Это пойдет: http://www.lighttpd.net/documentation/proxy.html ?

Есть еще смешанные методики, вроде "многопроцессность + мультиплексирование" или "многопоточность + мультиплексирование". Однако идеальной нет - надо под конкретную задачу подбирать. Вообще, с мультиплексированием (оно же - машина состояний) - интересно, шустро, но сложно :)