Конфигурация nginx для хостинга статических файлов

Не ухудшит ли производительность именно try_files?

Если location прописаны правильно, то нет.

Ну и раз уж это статика, можно ещё кэш прикрутить средствами того же nginx.

Везде заменили автоиндекс [...] на «try_files $uri =404»

Мне всегда казалось, что автоиндекс на длинных дистанциях быстрее на малых директориях. Могу ошибаться.

Если location прописаны правильно, то нет.

Что вы имеете в виду? Их практически нет. Обычно максимум «location /» и такие вещи:

location = / {
    index index.html;
}

location = /index.html {
    internal;
}

Ну и раз уж это статика, можно ещё кэш прикрутить средствами того же nginx.

Это есть.

P.S. Уточню. Речь о хостинге статических файлов на отдельных хостах.

Речь о хостинге статических файлов на отдельных хостах.

То есть CDN?

Если location прописаны правильно, то нет.

Что вы имеете в виду? Их практически нет.

nginx идёт по конфигу в порядке декларации. Если там куча location с rewrite и прочим, каждый запрос он будет прогонять логику.

То есть CDN?

Похоже в плане размещения файлов и их адресации. Но никаких «точек присутствия» и «гео-маршрутизации» нет. По крайней мере пока.

Конфигурация nginx для хостинга статических файлов - это дефолтная его конфигурация. То есть прописываешь root и всё, больше ничего указывать не надо.

server {
  listen ip:443 ssl;
  /// настройки сертификатов
  server_name example.ru;
  access_log /path/to/access.log;
  error_log /path/to/error.log notice;
  root /path/to/rootdir;
}

Ну и раз уж это статика, можно ещё кэш прикрутить средствами того же nginx.

А нахрена статику то кэшить? Проставить заголовки expires, пусть клиент кэшит ;)

Конфигурация nginx для хостинга статических файлов - это дефолтная его конфигурация.

Вопрос в том, будет ли показанная try_files хуже в плане производительности?

«Дефолтную» конфигурацию всегда дополняли файлом главной страницы (предпочтение отдавалось статусу 200, а не 404) и «кастомной» страницы ошибки 404. Ошибку 403, возникающую на каталогах, заменяли на 404. Если не использовали автоиндекс.

А нахрена статику то кэшить? Проставить заголовки expires

Наверное, это и имелось в виду, т.е. управление клиентским кэшированием.

В плане производительности парсинг и выполнение конфига в любом случае незаметны по сравнению с временем на доступ к диску.

Вопрос в том, будет ли показанная try_files хуже в плане производительности?

Ну или тестировать, или я даже и не знаю. Листинг директории по определению так то медленнее, например. Если у тебя планируется RPS в несколько сотен, ну тогда да, имеет смысл заморачиваться. Но, насколько я понимаю, ты нихрена не Озон или кернел.орг, к примеру и для тебя разница в производительности настолько смешна, что ой.

В плане производительности парсинг и выполнение конфига в любом случае незаметны по сравнению с временем на доступ к диску.

Речь именно про доступ к диску при использовании try_files. Например, не будет ли лишних stat syscall-ов и т.п. при использовании данной директивы? Конечно, хотелось бы узнать и о реальном опыте использования данной директивы применительно к хостингу статических файлов.

Сделали простую «поведенческую» правку конфигурации. Но возник вопрос, не станет ли хуже.

Скорее всего не будет (откуда бы им взяться?) но можешь проверить через strace.

Листинг директории по определению так то медленнее, например.

От листинга средствами web-сервера однозначно отказались. Используем свою реализацию в тех редких случаях, когда это нужно. Я «приплел» к вопросу автоиндекс, чтобы сказать, что ранее был такой альтернативный вариант для «error_page 403 =404 /index.html». Наверное, было бы проще не упоминать автоиндекс вовсе. Давайте не будем рассматривать вариант с листингом.

Естественно, try_files медленнее чем прямое указание на файл (выполняется какой-никакой поиск). Но разницы в производительности вы НЕ заметите.

Какой ещё поиск?

location / {
    try_files $uri $uri/ =404;
}

Здесь оверхеда нет.

location / {
    try_files $uri $uri/ @backend;
}

location @backend {
    proxy_pass http://backend.example.com;
}

Здесь оверхед есть. Под поиском я имел виду проверку существования файла. В любом случае вопрос выеденного яйца не стОит.

Основная причина — последовательные системные вызовы stat для проверки существования файлов и каталогов на диске. Когда Nginx обрабатывает try_files, он по очереди проверяет каждый аргумент: Первый аргумент ($uri) — проверяет, существует ли запрошенный файл. Второй аргумент ($uri/) — проверяет, является ли запрошенный путь директорией.

И что? При чём тут это? Ты читал вопрос темы то?

Никакого «оверхеда» второй случай по сравнению с первым не добавляет. Но к теме ни первый ни второй пример не относятся.

Второй аргумент ($uri/) — проверяет, является ли запрошенный путь директорией.

В моем варианте этого вообще нет. Вопрос, не будет ли try_files хуже и без этого ($uri/)?

Грубо говоря, сравниваем «try_files $uri =404» с «дефолтным» «location / {}» (или полным отсутствием этого location-а).

Да не будет же.

Шта? Ты точно алгоритм как оно работает понимаешь? В первом случае сразу отлуп на 404, а о втором - сначала проверить «а есть ли файл» и если его нет - обратиться к бэкенду. Наверное, логично, что во втором случае будет сразу направить запрос в бэкенд алгоритмически проще, не?

Если ты предлагаешь слать все запросы в бэкэнд и уже из бэкэнда при необходимости отдавать статические файлы, то нет, это никакая не экономия, а наоборот лишний расход ресурсов - как минимум на лишнее звено в цепочке передачи трафика (чтение с диска -> nginx -> клиент проще, чем чтение с диска -> бэкэнд -> nginx -> клиент), а вообще, в большинстве случаев, ещё и на то, что бэкэнд раздачу файлов будет выполнять менее эффективным, чем nginx, способом.

Зачем ты сюда приплёл алгоритмическую простоту nginx-конфига, вообще непонятно. Если тебя беспокоит только она, то предлагаю такой конфиг: server { return 404; } - будет ещё «алгоритмически проще».

nginx идёт по конфигу в порядке декларации. Если там куча location с rewrite и прочим, каждый запрос он будет прогонять логику.

location по порядку в конфиге только регулярные выражения с ~ модификатором

А нахрена статику то кэшить?

Из своего кэша он отдаёт быстрее.

Проставить заголовки expires, пусть клиент кэшит ;)

Если это медия — да пожалуйста, сколько влезет. А если это js, то его надо бы освежать когда это надо, а не ждать пока на клиенте кэш прокиснет.

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

В контексте Nginx. Проекты разные бывают, бывает, где всё в бэк должно сыпаться, без статики. любом случае я обгадилось с первым вариантом ). Но идея и так ясна. try_files должен выполнить stat (), он для этого и сделан.

Если это медия — да пожалуйста, сколько влезет. А если это js, то его надо бы освежать когда это надо, а не ждать пока на клиенте кэш прокиснет.

Как выше написали, для статических файлов обычно не запрещают «версионирование» при помощи строки запроса (query string). Даже к изображениям иногда лучше добавить номер версии, чем переименовать файл. А для CSS/JS - это вовсе норма.

try_files $uri =404

Это разве не дефолтное поведение?

Ты главное клиентское кэширование настрой. Ничто так не ускорит обработку запроса, как отсутствие необходимости делать этот запрос (: Остальной онанизм становится важен только на Действительно Серьёзном трафике.

P.S. а нафига вообще автоиндекс?

Я не знаю, как в nginx это сделано и мне лень самому вместо топикстартера запускать strace, чтобы убедиться. Но вообще никуда смотреть не надо. Ты просто вызываешь open. Если он отработал, значит файл есть и ты его отдаёшь. Если он не отработал, ты смотришь на код ошибки. Если это ENOENT значит файла нет и ты обрабатываешь соответствующую логику.

Подозреваю, что nginx всё равно делает stat чтобы выставить заголовок Last-Modified и это ещё один способ проверить, существует ли файл.

Это разве не дефолтное поведение?

Насколько я понимаю, такая try_files «отключает» ошибку 403 и «дефолтную» переадресацию на каталогах. После полного отказа от автоиндекса решили сделать единообразно на всех хостах для статических файлов (и где был автоиндекс, и где его не было). Теперь «дефолтная» переадресация точно не нужна.

В своей реализации «листинга» используется вариант «try_files $uri @ back» (@ go, @ php, etc.) - не стали использовать единый индексный программный файл, а сделали по привычке через единую точку входа. Если там и будет переадресация, то скорее обратная: «с завершающим слэшем» на «без завершающего слэша».