После 6 месяцев разработки вышел (http://www.lighttpd.net/2010/8/13/1-4-27-p-neq-np) релиз http-сервера lighttpd 1.4.27 (http://www.lighttpd.net) в котором отмечено 28 исправлений. В частности, устранены проблемы с обработкой SNI и SSL_CTX_set_options в SSL-соединениях, исправлены ошибки, приводящие к задержке ответа (http://redmine.lighttpd.net/issues/show/2196) в mod_proxy и проблемам (http://redmine.lighttpd.net/issues/show/2217) с работой mod_cgi вкупе с Linux-ядром 2.6.34. В состав lighttpd включен новый обработчик fdevent-событий libev (server.event-handler = "libev" ), обработчик linux-rtsig удален из поставки. Изменен процесс задействования IPv6, который теперь используется при наличии на интерфейсе IPv6-адреса.URL: http://www.lighttpd.net/2010/8/13/1-4-27-p-neq-np
Новость: http://www.opennet.me/opennews/art.shtml?num=27620
Кто-нибудь использует его в реальном продакшне? Как он сейчас, насколько сливает/выигрывает у nginx?
Я использую его на FreeBSD и довольно давно. Про слив Nginx'у сказать не могу, ибо не использовал его, но сам веб-сервер весьма быстр (наверно засчет kqueue).
>Кто-нибудь использует его в реальном продакшне? Как он сейчас, насколько сливает/выигрывает у
>nginx?Раздает видео под Фрей хорошо и быстро.
Конфигурируется, на мой взгляд, проще nginxа.
nginx стоял одно время - я его снёс за ненадобностью.
Лайт - проще.
>Кто-нибудь использует его в реальном продакшне? Как он сейчас, насколько
>сливает/выигрывает у nginx?Юзают. Скажем гугл на ютубе, википедия, meebo и кто там еще. Ну и я юзаю. Вполне приятный сервак. Имеет как плюсы так и минусы vs nginx. Из плюсов - больше протоколов бэкэндов понимает чем нжинкс и конфиг менее задрюченный. Из минусов - не так хорошо как нжинкс масштабируется на многопроцессорных машинах (нжинкс может запустить несколько воркер-процессов, логично развесить по процессу воркера на каждый проц). И еще лайти имеет дурную привычку буфферизовать ответ backend-а, так что если бэкэнд отдает много дряни - будет кушаться довольно много памяти под буфер ответа бэкэнда, nginx в этом плане ведет себя лучше. Кого выбрать? Для слабых 1-процессорных систем ориентированных на отдачу статики лайт как правило кушает меньше RAM т.к. всего 1 небольшой процесс на все и вся (у нжинкса минимум два). Сие актуально на старых машинах, небольших коробочках, вдс и прочая, особенно если вебсервер не единственное что там есть. Для многоядерных систем или если планируется что бэкэнд может сгенерить ажно iso-sized ответ скриптом - нжинкс подойдет больше. Лично мне в итоге пришилсь по вкусу оба и кого куда воткнуть определяется ситуацией и хотелками.
< Из минусов - не так хорошо как нжинкс масштабируется на многопроцессорных машинах (нжинкс может запустить несколько воркер-процессов, логично развесить по процессу воркера на каждый проц).А как же spawn-cgi? Хотя это отдельная штука, в принципе. Имею ввиду, что он не разрабатывается авторами lighttpd.
> А как же spawn-cgi?Имелся в виду сам лайти а не бэкэнд. Правда, ситуацию когда его процессу не хватит 1 процессора трудновато себе представить (он экономично ресурсы кушает), но сам по себе он гоняет как максимум несколько тредов под свои нужды, так что сам по себе лайти как процесс сложнее размазать на множество CPU если вдруг возникнет такая нужда а железо позволяет. Хотя это по идее должно быть крайне редкой ситуацией. На практике скорее может задолбать кеширование ответа бэкэнда. Науке известны случаи когда скрипт на бэкэнде взглючивал и генерил бесконечную портянку ответа. Ну а лайти ее пытался сбуферизовать. Ессно неуспешно.
Пробовал на продакше. Конечно, по сравнению с апачем отзывчивость системы лучше, что касается nginx - так у того скрипт, который обеспечивает работу php на определённом порту, к которому переадресует запросы nginx, падает раз в 15 минут на стабильном debian. Конечно, это не проблема nginx, но факт остаётся фактом: нормальной вменяемой реализации fastcgi у nginx пока нет. Кроме этого неприятного казуса никакой разницы между nginx и lighttpd никто не почуствовал. Система тогда была не оптимизирована, 8 ядер проца грузились по 20-30% постоянно симфонией. В таких условиях я пробовал apache, nginx и lighttpd. В итоге мы оптимизировали сам сайт до уровня по 2-3% на проц и вернулись на апач для удобства, очень важен mod_rewrite. В принципе правила я прописывал для всех троих серверов, всё работало правильно, но на lighttpd и nginx rewrite работает с некоторыми странными нюансами, которыми апач не страдает.
На 8-ядерном серваке (если у него много гигазов оперативы) может и не особо заметно (если там только опач и ничего кроме него), но тем не менее, апач, как минимум с префорк воркером - жутчайше жрет оперативу, в том числе и при отдаче статики. Несколько тысяч конекций - и вот уже оператива выжрана многочисленными процессами апача (а если их число ограничить - тогда юзеры будут долго ждать своего обслуживания). При том что создать эти конекции может даже тормозной DSLщик. Lighttpd или нжинкс будучи машинами состояний, не плолдящими новые процессы или треды на конекции - к всему этому пофигистичны. Расход ресурсов в пересчете на юзера, а точнее коннекцию на статике - невелик. Кроме того видел фокус когда замена апача на нжинкс улучшила время отклика на статике так что это стало попросту заметно на глаз. С опачем жпеги с сервера грузились с заметной на глаз задержкой. С нжинксой стали просто вылетать на экран как из пушки. Для статики нжинкса или лайт явно заруливают опача в хлам. Для динамики - тут зависит от (зачастую динамику можно кешануть в статику :P).
Регэкспы у реврайта в nginx = регэкспы Перла. не замечал особых проблем с этим, хотя... надо бы поискать бенчмарки, что ли. :)
>но факт остаётся фактом: нормальной вменяемой реализации fastcgi у nginx пока нетв nginx нормальная и вменяемая реализация fastcgi уже почитай лет 5, то что у вашего бэкэнда невменяемая реализация fastcgi это факт, ок
отличный веб-сервер,особенно будет классный, когда добавят mod-deflate, а в версии 2.0. еще и многопоточность и mod_header
А кто-нибуь использует LiteSpeed? Не щупал его, но, говорят, что он не хуже, а даже получше.
я использую (из крупных проектов знаю wordpress.com - правда щас идет процесс избавления от оного и на бэкендах )
из минусов - платный , конфигурация через веб-интерфейсиз плюсов - почти полная замена апачу - поддерживает его конфиги (хтаццессс.. ревреайты и проч) и даже конфиги апачевского мод_секурити . так же там собирается свой пхп с каким-то эдаким патчем.
хтаццессы не читаются при каждом запросе во всех директориях от документрут, а кешируются на всё время жизни процесса (т.е. раз прочли и больше не лезим в него.)