13 521
правка
Изменения
→ngx_http_perl_module
=== ngx_http_perl_module ===
Идея — вызов Perl-кода из [http://nginx.ru/ nginx].
Ссылка на документацию: [http://sysoev.ru/nginx/docs/http/ngx_http_perl_module.html http://sysoev.ru/nginx/docs/http/ngx_http_perl_module.html].
Плюсы:
* Возможность вызова Perl-кода из SSI, что делает nginx почти шаблонизатором.
* Простота, благодаря которой количество источников мистических ошибок, а также неуловимых утечек памяти сводится почти к нулю.
Минусы:
* Идея размещения приложения внутри nginx несколько лишает nginx его легковесности. Появляются Также появляются некоторые проблемы с масштабируемостью в случае простоев (ожиданий ответов от СУБД и т. п.).
* Жёсткая завязка на использование внутри nginx. Больше нигде приложения, написанные под nginx, не заработают.
* Отсутствие поддержки CGI среды внутри ngx_http_perl_module, наподобие mod_perl апача.
* Версии ngx_http_perl_module до 0.6.22 имели следующие особенности:
: Значения, возвращаемые методами объекта запроса $r, во-первых, хранились в памяти, выделяемой не perl’ом, а nginx’ом из собственных пулов, что в большинстве случаев позволяло уменьшить число операций копирования, а во-вторых, не завершались нулевым байтом. В некоторых ситуациях это приводит к ошибкам, например, при попытке использования таких значений в численном контексте, или использования незавершённых нулём строк в именах файлов и тому подобном:
:* (FreeBSD) <pre>nginx in realloc(): warning: pointer to wrong page
Out of memory!
Callback called exit.</pre>
:* (Linux) <pre>*** glibc detected *** realloc(): invalid pointer: ... ***
Out of memory!
Callback called exit.</pre>
: Обход этих особенностей простой — нужно просто скопировать возвращённое значение в скаляр. Например, <source lang="perl">my $i = $r->variable('counter') + 1;</source> заменить на <source lang="perl">my $i = $r->variable('counter'); $i++;</source>
== Standalone ==