Lighttpd

Материал из Eludia.

Перейти к: навигация, поиск


Эта заметка не претендует на энциклопедичность. Она не отличается ни широтой охвата, ни строгостью формулировок. Это просто записочка на память.

Содержание

Проходят годы, все мы не молодеем, вот и Apache... не в лучшей форме за свою историю. Тому есть объективные технологические причины. В чём бы они ни заключались, необходимо осваивать новые WEB-сервера, не обременённые грузом обратной совместимости, даже на платформе UNIX.

Сопоставление с аналогами

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

  • экономичность, каковой нет у Apache;
  • гибкая текстовая конфигурация — у IIS её не будет никогда;
  • доступность mod_fastcgi с собственным управлением процессами по умолчанию (для IIS его пока надо доставлять, а nginx работает только с внешними процессами, по TCP).
  • доступность как под UNIX/Linux, так и под Windows (правда, на момент написания этого текста свой контейнер для FastCGI-процессов там не работает, так что для Win32 нижеописанное можно применять только в перспективе).

FastCGI / Perl на первый взгляд кажется шагом назад по сравнению с mod_perl: ведь тут нет шансов использовать загрузку модулей в shared memory. Однако, как показывает практика, одним из узких мест mod_perl является как раз использование лишней памяти серверами, которые образуются в избыточном количестве. Типовой ход для решения этой проблемы — настройка лёгкого реверсного proxy (например, того же lighttpd). Однако такая схема уже практически повторяет FastCGI, только там приходится настраивать 2 WEB-сервера и возникают некоторые дополнительные сложности.

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

Настройка под Debian Linux 5.0

Нижеописанные действия производились с lighttpd/1.4.19-5, установленным из стандартного deb-пакета с общедоступного репозитория Debian.

Приложение

По аналогии с IIS/fcgiext, мы старались максимально использовать структуру директорий унаследованную от Apache. Пришлось сделать только 2 изменения:

  1. дать пользователю www-data (из-под которого запускается lighttpd) право на запись в logs/error.log;
  2. создать в директории docroot файл 0.eludia следующего содержания: 
#!/usr/bin/perl

use Eludia::Content::HTTP::FCGI::lighttpd;

1;

(к сожалению, lighttpd не умеет передавать FCGI-процессам параметры командной строки, так что отделаться пустым файлом, как в случае с IIS/fcgiext, не удалось).

Собственно lighttpd

В файл /etc/lighttpd/lighttpd.conf был добавлен следующий фрагмент: 

$SERVER ["socket"] == "192.168.0.40:7001" {

 var.root    = "/var/projects/my_application/"
 server.document-root = var.root + "docroot/"

 $HTTP["url"] =~ "^/i/" {
    expire.url = ("" => "access 1 months")
 }

 index-file.names = ("0.eludia")

 fastcgi.server = (

  ".eludia" => ((
    "bin-path"    => var.root + "docroot/0.eludia",
    "check-local" => "disable",
    "socket"      => "/tmp/my_application.socket",
    "min-procs"       => 1,
    "max-procs"       => 2,
    "idle-timeout"    => 20
  )))

}

После перезапуска lighttpd приложение заработало на 7001 порту.

Получено с http://www.eludia.ru/wiki/index.php/Lighttpd
Личные инструменты
Консультации
Разработчику
Администратору