LINUX.ORG.RU
Ответ на: комментарий от cppprogrammer_plus_admin

память нынче на развес продают.

даже у вас какое то брендированное/древнее железо

anonymous
()

Лайти чуть более прожорлив. В основном память съедает PHP, который всё равно будет реализован либо через FastCGI либо через Apache.

unikum ★★★★★
()

Ресурсов жрут оба мало.

Много лет Лайти был шустрее, но с год назад Энжинкс его по производительности обогнал. На статике, естественно, так как PHP у них одинаков.

У nginx в плюсах гибкая (хотя и достаточно инопланетная по логике) система конфигов.

У lighttpd в плюсах встроенный fcgi-сервер. Точнее, инфраструктура для поднятия и контроля fcgi.

Для меня они не заменяют, а дополняют друг друга, ни от одного нельзя отказаться. Исторически на основных машинах во фронтенте lighttpd, а nginx, где нужен, в бэкенде. Но надо, по хорошему, переделать, чтобы было наоборот.

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

а зачем вообще деление фронтент-бекенд при двух примерно равных по ресурсоемкости и производительности серверах? ладно если бы бекендом был апач.

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

а зачем вообще деление фронтент-бекенд при двух примерно равных по ресурсоемкости и производительности серверах?

Я же говорил — из-за встроенного в лайти fcgi-менеджера.

Поднять, скажем, trac или mercurial-репозиторий на lighttpd в виде fcgi — это пара команд конфига. И лайти сам озаботится о том, чтобы запустить fcgi и будет следить за его работоспособностью.

nginx так не умеет и придётся городить отдельный init-скрипт для подъёма fcgi, отдельный вотчдог для контроля работоспособности и т.п.

Просто вопрос удобства :)

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

Поднять, скажем, trac или mercurial-репозиторий на lighttpd в виде fcgi — это пара команд конфига

nginx так не умеет и придётся городить отдельный init-скрипт для подъёма fcgi

Если надо пустить те же trac и mercurial от другого пользователя, таки придется писать init-скрипт.

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

Да, но учитывая данную узкую специфичность задачи, вполне достаточно пускать под лайти их и от одного пользователя.

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

Не, он вообще ничего не умеет. Т.е. не конкурент lighttpd/nginx, просто маленький сервер с ограниченой логикой. Т.к. он наш, то на некоторых серверах у нас часть конфига компилируется с исходниками. Держит довольно большие нагрузки, но если нужно завести что-то глобальное со сложными реврайтами, то тут уже nginx.

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

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

Так чем он лучше лайти в роли fcgi-фронтенда?

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

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

У nginx в плюсах гибкая (хотя и достаточно инопланетная по логике) система конфигов

nginx_lua_module обеспечит ещё и иногалактическую логику, и прибавит скорости. Хотя я, как nginx-админ, не показатель.

riki ★★★★
()

ОП, к тебе 3 раза в день заходят и ты каждый метр экономишь? тогда юзай xinetd + nginx или апач. xinetd позволит запускать сервер только когда клиент делает запрос. а потом его убивать. экономия 100%. и можно юзать апач, а не трахаться с этой фигнёй.

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

nginx_lua_module обеспечит ещё и иногалактическую логику, и прибавит скорости. Хотя я, как nginx-админ, не показатель.

этот модуль на примерах показался мне более, чем понятным, читабельным и позволяющим делать велосипеды, рулить и педалить извращениями усилием мысли.
а вот ngx_http_perl_module, имхо, реализует логику из другого измерения даже :) и, судя, по проблемам, которые перловики обсуждали касательно него, у него большие проблемы с инъекциями и безопасностью.

vendor501
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.