Заточка lighttpd для Друпала

Аватар пользователя emzi emzi 15 января 2008 в 3:02

1. проапгрейдиться до lighttpd версии не менее 1.4.13 скомпилированным с поддержкой lua и lua версии не менее 5.1
2. в lighttpd.conf в разделе server.modules указать "mod_magnet",
3. ниже, в основном конфиге, либо в конфиге виртуального сервера написать строчку:
magnet.attract-physical-path-to = ( server.document-root + "/rewrite.lua" )
обратить внимание на то, чтобы переменная server.document-root уже содержала к этому времени значение каталога, в которомнаходится Drupal
4. в корневом каталоге сайта, там же, где обычно находится .htaccess создать файл rewrite.lua, в который поместить текст следующего содержания:

attr = lighty.stat(lighty.env["physical.path"])
if (not attr) then
    lighty.env["physical.path"] = lighty.env["physical.doc-root"] .."index.php"
    if(lighty.env["uri.query"]) then
        lighty.env["uri.query"]="q="..lighty.env["physical.rel-path"].."&"..lighty.env["uri.query"]
    else
        lighty.env["uri.query"]="q="..lighty.env["physical.rel-path"]
    end
end

5. перезапустить lighttpd

Суррогатное решение можно получить и в предыдущих версиях lighttpd, без использования модуля mod_magnet, однако поскольку в этом случае проверка на существование файлов проводиться не будет, возможны различные неприятные сюрпризы.
Полная версия лежит тут.

Комментарии

Аватар пользователя VLAD_X VLAD_X 15 января 2008 в 7:55

В чём +/- такого способа преобразования адресов по сравнению со встроенным в lighttpd? А по сравнению с nginx и mod_rewrite в Apache?
Думается, подгрузка интерпретатора lua при КАЖДОМ запросе, создаст дополнительные нехилые тормоза.

Аватар пользователя axel axel 15 января 2008 в 11:50

Встроенный интерпретатор скриптового языка конечно даёт гибкость (в nginx к примеру прицеплен perl), но в данном случае невозможность разрулить правила преобразований апачевского mod_rewrite скорее выглядит как недостаток lighttpd.

Аватар пользователя emzi emzi 16 января 2008 в 2:38

VLAD_X wrote:
В чём +/- такого способа преобразования адресов по сравнению со встроенным в lighttpd

главное и основное преимущество в том, что проверяется фактическое наличие запрашиваемого файла и преобразование clean url выполняется только если это необходимо. Это также может быть полезно, если двигаться дальше и выполнять кэширование средствами lighttpd.
Не думаю, что "подгрузка интерпретатора lua" происходит при каждом запросе, впрочем, изменение нагрузки можно при необходимости определить экспериментально.

Аватар пользователя emzi emzi 15 января 2008 в 12:16

невозможность разрулить правила преобразований апачевского mod_rewrite - немного не понял, это в каком случае?

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

Аватар пользователя axel axel 15 января 2008 в 15:24

Как я понял из статьи, сделать проверку наличия файлов средствами конфига lighttpd нет возможности - нужно передевать url скрипту, который этим займётся. Я не занимался этой задачей под lighttpd, но под nginx можно сделать проверку наличия директорий/файлов и воспроизвести любые регвыражения из mod_rewrite. Поэтому заключил, что в случае lighttpd это недостаток - модуль вебсервера полагаю исполнит эти задачи быстрей, чем скрипт.

Аватар пользователя emzi emzi 16 января 2008 в 2:36

axel wrote:
Как я понял из статьи, сделать проверку наличия файлов средствами конфига lighttpd нет возможности - нужно передевать url скрипту, который этим займётся

нет, это не совсем так - определить наличие файла с помощью mod_rewrite действительно нельзя, но mod_magnet - это модуль lighttpd, который (как утерждается) выполняется в ядре, файл со скриптом кэшируется и недостаток по сравнению с жестким конфигом только в том, что постоянно проверяется "свежесть" файла.

Аватар пользователя emzi emzi 16 января 2008 в 22:25

<a href="mailto:PhAbyss@drupal.org">PhAbyss@drupal.org</a> wrote:
А чем он лучше nginx с fastcgi?

Да ничем. php там тоже через fastcgi. Просто бывают ситуации, когда приходится работать с тем, что есть.