Модуль ngx_http_ssi_module
Модуль ngx_http_ssi_module — это фильтр, обрабатывающий команды SSI (Server Side Includes) в проходящих через него ответах. На данный момент список поддерживаемых команд SSI неполон.
Пример конфигурации
Директивы
| Синтаксис: | ssi on | off ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location , if в location |
Разрешает или запрещает обработку команд SSI в ответах.
| Синтаксис: | ssi_last_modified on | off ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Эта директива появилась в версии 1.5.1.
Позволяет сохранить поле заголовка “Last-Modified” исходного ответа во время обработки SSI для лучшего кэширования ответов.
По умолчанию поле заголовка удаляется, так как содержимое ответа изменяется во время обработки и может содержать динамически созданные элементы или части, которые изменились независимо от исходного ответа.
| Синтаксис: | ssi_min_file_chunk размер ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Задаёт минимальный размер частей ответа, хранящихся на диске, начиная с которого имеет смысл посылать их с помощью sendfile.
| Синтаксис: | ssi_silent_errors on | off ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Разрешает не выводить строку “ [an error occurred while processing the directive] ”, если во время обработки SSI произошла ошибка.
| Синтаксис: | ssi_types mime-тип . ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Разрешает обработку команд SSI в ответах с указанными MIME-типами в дополнение к “ text/html ”. Специальное значение “ * ” соответствует любому MIME-типу (0.8.29).
| Синтаксис: | ssi_value_length длина ; |
|---|---|
| Умолчание: | |
| Контекст: | http , server , location |
Задаёт максимальную длину значений параметров в SSI-командах.
Команды SSI
Общий формат команд SSI такой:
Поддерживаются следующие команды:
block Описывает блок, который можно использовать как заглушку в команде include . Внутри блока могут быть другие команды SSI. Параметр команды: name имя блока. Пример:
Встроенные переменные
Модуль ngx_http_ssi_module поддерживает две встроенные переменные:
$date_local текущее время в локальной временной зоне. Формат задаётся командой config с параметром timefmt . $date_gmt текущее время в GMT. Формат задаётся командой config с параметром timefmt .
Источник
Nginx с memcache, gunzip и ssi не работают вместе
Я пытаюсь сохранить упакованный (gzip) html в Memcached и использовать его в nginx:
загрузить html из memcached с помощью модуля memcached распаковать модуль nginx gunzip, если он упакован процесс ssi вставки с помощью модуля ssi вернуть результат пользователю
в основном, работы по настройке, кроме шага ssi:
Похоже, nginx do ssi обрабатывает перед распаковкой с помощью модуля gunzip.
В результате HTML я вижу нерешенные инструкции ssi:
Ошибок в журнале nginx нет.
Попробовали ssi_types * — нет эффекта
Любая идея, как это исправить?
nginx 1.10.3 (Ubuntu)
ОБНОВИТЬ
Попробовали с еще одним восходящим потоком. Тот же результат = (
В журнале, я вижу, ssi фильтр применяется после запроса на восходящий поток, но без обнаруженных включений.
Я хочу избежать решения с помощью динамических модулей nginx, если возможно
В основном есть два вопроса, которые необходимо учитывать: подходит ли порядок фильтрующих модулей и работает ли gunzip для вашей ситуации.
0. Порядок gunzip/ssi/gzip.
Простой поиск «порядка модулей nginx модулей» показывает, что порядок определяется во время компиляции на основе содержимого сценария оболочки auto/modules :
Несколько фильтров могут подключаться к каждому местоположению, так что (например) ответ может быть сжат, а затем помечен. Порядок их исполнения определяется во время компиляции. У фильтров есть классический шаблон дизайна «ЦЕПОЧКА ОТВЕТСТВЕННОСТИ»: один из них вызывается, выполняет свою работу, а затем вызывает следующий фильтр, пока не вызывается последний фильтр, и Nginx завершает ответ.
Порядок фильтров определяется порядком выполнения модулей nginx. Порядок выполнения модулей nginx реализуется в файле auto/modules в исходном коде nginx.
Быстрый взгляд на auto/modules показывает, что ssi находится между gzip и gunzip , однако не сразу выясняется, каким образом модули выполняются (сверху вниз или снизу вверх), поэтому значение по умолчанию может быть либо разумным, либо вы может потребоваться переключить два (которые не обязательно будут поддерживаться, IMHO).
Одним из намеков является расположение фильтра http_not_modified , который приведен в качестве примера обработки If-Modified-Since в руководстве EMiller выше; Я бы предположил, что это должно быть последним, после всех остальных, и, если да, то, действительно, кажется, что порядок gunzip/ssi/gzip точно противоположный тому, что вам нужно.
1. Работает ли gunzip?
Согласно http://nginx.org/r/gunzip, следующий текст присутствует в документации для фильтра:
Включает или отключает декомпрессию gzipped-ответов для клиентов, которым не хватает поддержки gzip.
Не совсем ясно, следует ли рассматривать приведенный выше оператор как описание модуля (например, клиенты, не имеющие поддержки gzip, именно поэтому вы можете использовать этот модуль), или это описание поведения (например, независимо от того, модуль сам определяет, будет ли gzip поддерживаться клиентом). Исходный код в src/http/modules/ngx_http_gunzip_filter_module.c, по- видимому, означает, что он просто проверяет, является ли Content-Encoding ответа as-is gzip , и действуйте, если это так. Однако следующее предложение в документах (после приведенного выше цитирования), похоже, указывает на то, что оно имеет некоторое взаимодействие с модулем gzip , поэтому, возможно, что-то еще задействовано.
Я предполагаю, что если вы тестируете браузер, то браузер поддерживает gzip, поэтому было бы разумно, чтобы gunzip не включался, поэтому модуль SSI никогда не имел бы ничего действительного для обработки. Вот почему я предлагаю вам определить, работает ли gunzip корректно и/или по-разному между выполнением простых простых текстовых запросов через curl сравнению с теми, которые сделаны браузером с Accept-Encoding который включает gzip .
В зависимости от результатов расследования, как указано выше, я попытался бы определить порядок модулей, и, если это неверно, выбор был бы рекомпиляцией или двойным проксированием.
Впоследствии, если проблема все еще не исправлена, я гарантирую, что фильтр gunzip безоговорочно выполнит декомпрессию данных из memcached ; Я бы предположил, что вам, возможно, придется игнорировать или перезапускать заголовки Accept-Encoding или некоторые из них.
Источник
SSI в nginx такой медленный?
Два ноутбука, связаны между собой 50мбитным Wi-Fi, на одном сервер, на другом клиент, клиент производит замер используя ab:
Железо значение не имеет, у всех оно разное.
За эталон возьмём статичный blank.html весом пусть пару байт.
Сервер обрабатывает порядка 9000 запросов в секунду, процессор едва ли нагружен, порядка 20% на ядро. Значит, любая другая статика, читай, закэшированные php-скрипты (такая же .html статика) должны отрабатывать с тем же результатом.
Возьмём пустой .php скрипт, этот файл должен прогоняться через интерпретатор php и выдавать результат веб-серверу, а веб-сервер клиенту, — ab сообщает об обработке 2000 запросов в секунду, что для «динамики», имхо, неплохой результат. Все процессы php-fpm и nginx нагружают процессор сервера на 100%.
Теперь включаем кэширование сайта с динамичными блоками, которые включаются на странице при помощи SSI, , — кэшируется страница, кэшируется этот SSI-блок для каждого юзера в отдельности, потом страница собираются и отдаётся пользователю. Включаем ssi on; в конфиге nginx, и сервер обрабатывает около 2500 запросов в секунду, что мягко говоря, для закэшированной страницы ОЧЕНЬ мало, потому что от статики я ждал тех самых 9000 запросов/сек. Эти же самые 2000 тире 2500 запросов в секунду мне выдаёт обычный php без кэширования.
Правда, благодаря кэшированию, процессор теперь отдыхает, php не дёргается.
Теперь отключаем ssi off; , попробуем запросить закэшированную страницу /user_info.php, и получаем те самые завестные 9000 запросов в секунду, Карл!
Включаю SSI — получаю 2000 rps на статике, ВЫключаю SSI — получаю максимальные 9000 rps на статике.
По итогам, SSI и HighLoad — вещи несовместимые, никак. Получается, если нужна максимальная отдача сервера, SSI должен быть отключён, а страницы должны быть закэшированы полностью, и никаких блочных вставок, никакой «сборки страницы» на стороне сервера. Страница должна кэшироваться со всеми «динамическими вставками» целиком, иначе получается херня.
Источник
Не работает ssi on nginx
Не работает кеширование SSI в nginx.
Сделал специально простой конфиг:
В браузере выглядит так:
Пробовал с proxy_pass и простыми html-ками — тоже самое (дело не в fastsgi бекэнде)
Файл кеша создается:
С выключенным кешем работает.
izbushka, закэшируйте отдельный локейшен, который будет делать запросы к бэкенду.
У меня все запросы к бекенду..
И мне надо кешировать и саму страницу и ее инклуды, на разное время
izbushka, выделите для ssi отдельный локейшен, который будет получать данные у cgi, и его кэшируйте, а обработку cgi вынестите тоже в отдельный локейшен. Соответственно если кэш живой — отдавать из кэша, кэша нет или он истек — запрашивать у cgi. Стандартный метод кэширования.
ps. Хороший сервис делаете, привет соседям (:
Да, так работает, но проблема опять появляется когда использую многоуровневые ssi вложения: т.е. включаю ssi внутри ssi.
Что можно сделать в этом случае? Плодить locations? Становится неудобно следить за тем, как именно надо подключать ssi в конкретном месте, чтоб он попал в другой location.
izbushka, скорее всего ssi внутри ssi и не будет отрабатывать, тк это статические данные и, попав в кэш, они больше не будут как-либо обрабатываться. Тут придется менять уже структуру ресурса.
Предлагают юзать $uri вместо $request_uri как ключ кеша, но у меня пока не работает (гуглю).
Простой вариант, даже не требующий отдельного location для ssi, это включать SSI с GET параметром, указывающим на уровень его вложенности (level=N) и добавить $query_string в ключ кеша.
Читаю дальше, спасибо за наводку, в любом случае
Источник
Русские Блоги
ssi и настройте ssi с помощью nginx
При создании веб-сайта на странице будет много дублирующегося контента, поэтому излишне писать каждую страницу один раз, и ее легко пропустить при изменении, так что вы можете написать открытую часть в отдельном HTML и использовать ее для справки. ,
Несколько способов представить другие файлы HTML в файлах HTML
Этот блог очень подробный.
Третий метод включения в этом блоге приводит к следующему.
SSI: Server Side Include — это технология производства веб-страниц на основе сервера. Большинство веб-серверов (особенно Unix), таких как Netscape Enterprise Server, поддерживают команды SSI.
Это работает потому, что: перед тем, как содержимое страницы отправляется клиенту, используйте инструкции SSI для включения текста, изображений или информации о коде на веб-страницу. Для повторяющегося содержимого в нескольких файлах использование SSI — это простой способ сохранить содержимое в одном включаемом файле, не вводя его во все файлы. Включаемый файл вызывается с очень простым оператором, который инструктирует веб-сервер вставлять контент в соответствующую веб-страницу. Кроме того, при использовании включаемых файлов все изменения содержимого могут быть сделаны в одном месте.
Связанный пост в блоге
3. Включить SSI в nginx
Добавьте следующую команду настройки в nginx.connf
(Можно добавить две строки кода, которые я добавил, см. Следующие три абзаца, добавленные в блоге других людей
Может быть размещен перед первым сегментом сервера или непосредственно добавлен к сегменту сервера следующим образом:
Примечание:
файл Имя файла — это относительный путь относительно каталога, в котором находится документ с использованием директивы #include. Включенные файлы могут находиться в том же каталоге или его подкаталогах, но не в родительском каталоге. Например, файл nav_head.htm в текущем каталоге имеет вид file = ”nav_head.htm”.
имя виртуального файла — это полный путь к виртуальному каталогу на веб-сайте. Например, относительно файла nav_head.htm в каталоге hoyi в корневом каталоге документа сервера; virtual = ”/ hoyi / nav_head.htm”
Разница между включаемым файлом и виртуальным включением
1. # включаемый файл Относительный путь к включаемому файлу, #include virtual включает виртуальный путь к файлу.
2. В одном и том же виртуальном каталоге и Эффект тот же, но если предположить, что виртуальный каталог называется myweb, то также можно отлаживать, но мы знаем, что абсолютно неправильно.
3. Если на одном сайте есть 2 виртуальных каталога myweb1 и myweb2, file1.asp в myweb1 и file2.asp в myweb2, если file1.asp вызывает file2.asp , Затем напишите в file1.asp следующим образом: . В этом случае использование файла #include невозможно. include file = «myweb2 / file2.asp» -> Необходимо сообщить об ошибке. И наоборот, то же самое верно для файлов, включенных в myweb2 в myweb2. Если включенный файл находится в папке, просто добавьте папку в виртуальный путь.
4. Независимо от использования файла #include или виртуального #include, использование «/» или «/» в пути или их совместное использование не повлияет на эффект компиляции, и программа будет работать гладко.
5. Вышеуказанная ситуация не относится к взаимному вызову файлов с 2 сайтов и внутри одного сайта, и Эквивалентно, но при условии, что имя сайта является веб-сайтом, использование неверно.
Источник