Настроить кэширование файлов nginx
Обновлено: 07.07.2024
Настройка кэширования с помощью nginx позволяет прокси-серверу nginx кэшировать определенное динамическое содержимое сайта. Кэшированные данные хранятся в течение короткого периода времени (обычно не дольше нескольких секунд). Это может помочь сократить время загрузки сайта и уменьшить нагрузку на сервер.
Настройка кэширования с помощью nginx рекомендуется только для сайтов, обладающих определенными свойствами (например, для популярных блогов или новостных сайтов):
- Высокий трафик.
- Обновление контента каждые несколько секунд.
Настройка кэширования с помощью nginx может быть бесполезной и даже опасной для сайтов со следующими характеристиками:
- Умеренный или низкий трафик.
- Обновление содержимого реже, чем раз в несколько секунд.
- Использование персонализированных данных (например, данных о географическом местоположении посетителя сайта или содержимом его корзины).
Вы можете настроить кэширование с помощью nginx для отдельных доменов или хостинг-планов.
Чтобы включить кэширование с помощью nginx для хостинг-плана:
- Перейдите на страницу Тарифные планы.
- На вкладке “Хостинг-планы” нажмите Добавить план для создания нового плана или нажмите имя существующего плана для его редактирования.
- Перейдите на вкладку “Веб-сервер”.
- В разделе “Настройки nginx” поставьте галочку “Включить кэширование с помощью nginx”.
- (Необязательно) Вы можете изменить настройки кэширования с помощью nginx. Если вы не знакомы с кэшированием с помощью nginx, мы рекомендуем вам оставить настройки по умолчанию. Неправильная установка этих настроек может привести к снижению производительности сайта и сервера.
- Нажмите OK (или Обновить и синхронизировать в случае изменения существующего плана).
Теперь каждый раз при создании новой подписки на основе этого хостинг-плана кэширование с помощью nginx будет автоматически включаться на доменах и субдоменах этой подписки. Существующие подписки, основанные на этом хостинг-плане, не будут затронуты.
Информацию о том, как включить кэширование с помощью nginx для домена, смотрите здесь .
NGINX позволяет значительно ускорить процесс загрузки страницы, не обращаясь к бэкэнду, а выдавая готовый html из кэша. Для работы данной функции необходимо, чтобы веб-сервер был версии 0.7.44 и выше (проверить можно командой nginx -v).
Для FastCGI кэш задается с помощью опций fastcgi_cache_*. Для запросов к бэкэнду с помощью proxy_pass — proxy_cache_*.
Рекомендации и противопоказания
Кэш — это данные не первой свежести. Это важно учитывать, если мы хотим настроить эффективное кэширование средствами nginx. Мы можем столкнуться с различными проблемами, например, неспособность сервера продлить сессию авторизованного пользователя или отображение старой информации на портале с динамично меняющимся контентом. Чтобы избежать данных проблем, настройка nginx должна быть тесно сопряжена с разработкой сайта. Идеальная работа кэша возможна только при полном понимании внутренних механизмах работы портала, такие как, отправка запросов на авторизацию, продление сессии, обновлении контента — программист может написать для этого запрос по определенным URL, для которого администратор NGINX может отключить кэширование.
Кэширование динамики будет полезно для сайтов с высокой посещаемостью, из-за которой создается высокая нагрузка на сервер и он не может успеть выполнить обработку запросов. Также оно будет полезно для отдельных страниц, содержимое которых меняется очень редко, но отработка скриптов выполняется долго.
Настройка кэширования для proxy_pass
Как было сказано выше, для разных методов обращения к серверу, который обрабатывает запрос, нужно использовать разные методы кэширования.
Включение кэширования
Открываем конфигурационный файл nginx:
* в данном примере мы задали глобальную настройку для кэширования:
- /var/cache/nginx — путь хранения кэша.
- levels — уровень вложенности каталогов. В данном примере мы задаем настройку, при которой в каталог с кэшем будет создан каталог, а в ней — еще один каталог.
- keys_zone — имя зоны в разделяемой памяти, где будет храниться кэш, а также ее размер.
- inactive — задает время, после которого кэш будет автоматически чиститься.
- max_size — максимальный размер данных под кэш. Когда место заканчивается, nginx сам удаляет устаревшие данные.
Создаем каталог для хранения кэша и задаем владельца:
chown nginx:nginx /var/cache/nginx
Настройка хостов
Чтобы определенный сайт или отдельная страница кешировала запрос, открываем конфигурационный файл с настройками виртуального домена или хоста, например:
. и добавим к proxy_pass кэширование — мы получим что-то на подобие:
Применение настроек
NGINX настроен. Проверим корректность настроек:
Если ошибок нет, применяем их:
systemctl restart nginx
Теперь заходим на сайт и смотрим в каталог с кэшем — в нем должны появиться каталоги и файлы:
Мы должны увидеть что-то на подобие:
drwx------. 3 nginx nginx 4096 Jan 25 16:09 0
drwx------. 5 nginx nginx 4096 Jan 25 16:09 2
drwx------. 5 nginx nginx 4096 Jan 25 16:15 3
drwx------. 3 nginx nginx 4096 Jan 25 16:09 4
drwx------. 4 nginx nginx 4096 Jan 26 05:08 5
drwx------. 3 nginx nginx 4096 Jan 25 16:09 6
drwx------. 3 nginx nginx 4096 Jan 26 04:18 7
drwx------. 3 nginx nginx 4096 Jan 25 16:10 8
drwx------. 5 nginx nginx 4096 Jan 25 16:15 a
drwx------. 3 nginx nginx 4096 Jan 25 16:09 b
drwx------. 5 nginx nginx 4096 Jan 26 04:19 e
drwx------. 3 nginx nginx 4096 Jan 25 19:55 f
Настройка кэширования для fastcgi_pass
Настройка fastcgi_cache аналогична proxy_cache и настройки можно сделать по подобию последнего, заменив proxy_ на fastcgi_. Мы разберем основные настройки без подробностей и комментариев.
Открываем конфиг nginx:
* обратите внимание, что мы задали другой каталог и keys_zone.
Создаем каталог для кэша:
chown nginx:nginx /var/cache/fastcgi
Проверяем настройки и применяем их:
systemctl restart nginx
Кэширование статики
Кэширование статики не имеет никакого отношения к кэшированию ответа от бэкэнда, однако, это тоже позволяет разгрузить сервер. Суть в том, что nginx сам умеет отдавать статические файлы + задавать инструкцию для браузера по ее кэшированию.
Настройка выполняется для каждого виртуального хоста (секция server):
* ^.+\.(css|js)$ root /var/www/site
expires modified +1w;
>
location
* в данном примере мы задаем для файлов изображений (jpg, jpeg, gif, png) кэш до 31 декабря 2037 23:55:55 (max), для файлов css и js — 1 неделя с момента их модификации. Данные настройки мы задаем при помощи параметра expires, который, в свою очередь, задает заголовок cache-control. NGINX будет искать статические файлы в корневом каталоге /var/www/site.
После применяем настройки:
systemctl restart nginx
Отключение кэширования
Как говорилось выше, в некоторых случаях, кэширование может навредить и на некоторых страницах его стоит отключить. В настройках виртуального хоста, мы можем создать отдельный location, для которого отключиться кэш, например:
* обратите внимание, что в данном примере мы отключаем кэширование как для запросов proxy_pass, так и fastcgi_pass.
При отключении кэширования для статики используем следующую конфигурацию:
* ^.+\.(jpg|jpeg|gif|png|css|js)$ root /var/www/site
expires epoch;
>
>
* expires epoch задаст заголовок сache-control с временем окончания кэша "1 января 1970 00:00:01".
Сброс кэша
Удалить кэш на стороне сервера nginx мы можем только для бэкэнда. Для статики нужно удалять кэш в самом браузере (например, в настройках или с помощью дополнений).
Для сброса кэша мы просто должны удалить содержимое каталога, который прописан в опции proxy_cache_path или fastcgi_cache_path — в нашем случае, это /var/cache/nginx и /var/cache/fastcgi соответственно.
а) для proxy_cache_path:
б) для fastcgi_cache_path:
Хранение кэша в оперативной памяти
Мы можем значительно ускорить процесс записи и чтения информации, если будем хранить кэш в оперативной памяти.
Создаем обычный каталог, в который будем монтировать часть оперативной памяти:
. и дадим на него полные права:
chmod 777 /var/ramdisk
Монтируем часть оперативной памяти как обычный каталог:
mount -t tmpfs -o size=2G ramdisk /var/ramdisk
* в данном примере мы монтируем 2 Гб оперативной памяти как папку /var/ramdisk. Возможно, правильнее будет заранее убедиться в наличие свободной памяти командой free.
Для автоматического монтирования открываем на редактирование fstab:
ramdisk /var/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=2G 0 0
Теперь, когда у нас есть каталог, данные которого хранятся в оперативной памяти, редактируем параметр proxy_cache_path или fastcgi_cache_path в NGINX:
proxy_cache_path /var/ramdisk levels=1:2 keys_zone=all:64m inactive=2h max_size=2g;
fastcgi_cache_path /var/ramdisk levels=1:2 keys_zone=fastcgi:64m inactive=2h max_size=2g;
В жизни каждого проекта настает время, когда сервер перестает отвечать требованиям SLA и буквально начинает захлебываться количеством пришедшего трафика. После чего начинается долгий процесс поиска узких мест, тяжелых запросов, неправильно созданных индексов, не кэшированных данных, либо наоборот, слишком часто обновляемых данных в кэше и других темных сторон проекта.
Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.
Но если вас не покидает чувство, что ваш сервер способен на большее, или есть магический параметр, ускоряющий работу сайта в 100 раз, то можно вспомнить о встроенной возможности nginx, позволяющей кэшировать ответы от бэкенда. Давайте разберем по порядку, что это, и как это может помочь увеличить количество обрабатываемых запросов сервером.
Что такое Nginx cache и как он работает?
Для удобства можно вынести конфигурацию в отдельный файл, например “/etc/nginx/conf.d/cache.conf”. Давайте рассмотрим директиву “proxy_cache_path”, которая позволяет настроить параметры хранения кэша.
“/var/lib/nginx/proxy_cache” указывает путь хранения кэша на сервере. Именно в эту директорию nginx будет сохранять те самые файлы с ответом от бэкенда. При этом nginx не будет самостоятельно создавать директорию под кэш, об этом необходимо позаботиться самому.
“levels=1:2” — задает уровень вложенности директорий с кэшем. Уровни вложенности указываются через “:”, в данном случае будет созданы 2 директории, всего допустимо 3 уровня вложенности. Для каждого уровня вложенности доступны значения от 1 до 2, указывающие, как формировать имя директории.
Важным моментом является то, что имя директории выбирается не рандомно, а создается на основе имени файла. Имя файла в свою очередь является результатом функции md5 от ключа кэша, ключ кэша мы рассмотрим чуть позже.
Давайте посмотрим на практике, как строится путь до файла кэша:
“keys_zone=proxy_cache:15m” параметр задает имя зоны в разделяемой памяти, где хранятся все активные ключи и информация по ним. Через “:” указывается размер выделяемой памяти в Мб. Как заявляет nginx, 1 Мб достаточно для хранения 8 тыс. ключей.
“max_size=1G” определяет максимальный размер кэша для всех страниц, при превышении которого nginx сам позаботится об удалении менее востребованных данных.
Также есть возможность управлять временем жизни данных в кэше, для этого достаточно определить параметр “inactive” директивы “proxy_cache_path”, который по умолчанию равен 10 минутам. Если в течение заданного в параметре “inactive” времени к данным кэша не было обращений, то эти данные удаляются, даже если кэш еще не “скис”.
Что же из себя представляет этот кэш? На самом деле это обычный файл на сервере, в содержимое которого записывается:
• ключ кэша;
• заголовки кэша;
• содержимое ответ от бэкенда.
Если с заголовками и ответом от бэкенда все понятно, то к “ключу кэша” есть ряд вопросов. Как он строится и как им можно управлять?
Для описания шаблона построения ключа кэша в nginx существует директива “proxy_cache_key”, в которой в качестве параметра указывается строка. Строка может состоять из любых переменных, доступных в nginx.
Символ “:” между параметром куки и get-параметром используется для предотвращения коллизий между ключами кэша, вы можете выбрать любой другой символ на ваше усмотрение. По умолчанию nginx использует следующую строку для формирования ключа:
Следует отметить следующие директивы, которые помогут более гибко управлять кэшированием:
proxy_cache_valid — Задает время кэширования ответа. Возможно указать конкретный статус ответа, например 200, 302, 404 и т.д., либо указать сразу все, с помощью конструкции “any”. В случае указания только времени кэширования, nginx по дефолту будет кэшировать только 200, 301 и 302 статусы.
proxy_cache_lock — Эта директива поможет избежать сразу нескольких проходов на бэкенд за набором кэша, достаточно установить значение в положении “on”. Все остальные запросы будут ожидать появления ответа в кэше, либо таймаут блокировки запроса к странице. Соответственно, все таймауты возможно настроить.
proxy_cache_lock_age — Позволяет установить лимит времени ожидания ответа от сервера, после чего на него будет отправлен следующий запрос за набором кэша. По умолчанию равен 5 секундам.
proxy_cache_lock_timeout — Задает время ожидания блокировки, после чего запрос будет передан на бэкенд, но ответ не будет закэширован. По умолчанию равен 5 секундам.
proxy_cache_use_stale — Еще одна полезная директива, позволяющая настроить, при каких случаях возможно использовать устаревший кэш.
В данном случае будет использовать устаревший кэш в случае ошибки подключения, передачи запроса, чтения ответа с сервера, превышения лимита ожидания отправки запроса, чтения ответа от сервера, либо если в момент запроса происходит обновление данных в кэше.
proxy_cache_bypass — Задает условия, при которых nginx не станет брать ответ из кэша, а сразу перенаправит запрос на бэкенд. Если хотя бы один из параметров не пустой и не равен “0”. Пример:
proxy_no_cache — Задает условие при котором nginx не станет сохранять ответ от бэкенда в кэш. Принцип работы такой же как у директивы “proxy_cache_bypass”.
Возможные проблемы при кэшировании страниц
Следующая задача, с которой придется столкнуться — это управление кэшированием. Конечно можно установить незначительное время кэша в 2-5 минут и этого будет достаточно в большинстве случаев. Но не во всех ситуациях такое применимо, поэтому будем изобретать свой велосипед. Теперь обо всем по порядку.
Управление сохранением cookie
Управление сбросом кэша
Перед тем как начать писать свое решение, посмотрим, что предлагает nginx из “коробки”. Для сброса кэша в nginx предусмотрена специальная директива “proxy_cache_purge”, в которой записывается условие сброса кэша. Условие на самом деле является обычной строкой, которая при непустом и не “0” значении удалит кэш по переданному ключу. Рассмотрим небольшой пример.
Пример взят с официального сайта nginx.
За сброс кэша отвечает переменная $purge_method, которая является условием для директивы “proxy_cache_purge” и по дефолту установлена в “0”. Это означает, что nginx работает в “обычном” режиме (сохраняет ответы от бэкенда). Но если изменить метод запроса на “PURGE”, то вместо проксирования запроса на бэкенд с сохранением ответа будет произведено удаление записи в кэше по соответствующему ключу кэширования. Также возможно указать маску удаления, указывая знак “*” на конце ключа кэширования. Тем самым нам не нужно знать расположения кэша на диске и принцип формирования ключа, nginx берет на себя эти обязанности. Но есть и минусы этого подхода.
- Директива “proxy_cache_purge” доступна как часть коммерческой подписки
- Возможно только точечное удаление кэша, либо по маске вида “*”
Мы знаем, что nginx кэш — это обычный файл на сервере. Директорию для хранения файлов кэша мы самостоятельно указали в директиве “proxy_cache_path”, даже логику формирования пути до файла от этой директории мы указали с помощью “levels”. Единственное, чего нам не хватает, это правильного формирования ключа кэширования. Но и его мы можем подсмотреть в директиве “proxy_cache_key”. Теперь все что нам остается сделать это:
- сформировать полный путь до страницы, в точности как это указано в директиве “proxy_cache_key”;
- закодировать полученную строку в md5;
- сформировать вложенные директории пользуясь правилом из параметра “levels”.
- И вот у нас уже есть полный путь до файла кэша не сервере. Теперь все, что нам остается, это удалить этот самый файл. Из вводной части мы знаем, что nginx может быть расположен не на машине приложения, поэтому необходимо заложить возможность удалять сразу несколько адресов. Снова опишем алгоритм:
- Сформированные пути к файлам кэша мы будем записывать в файл;
- Напишем простой сценарий на bash, который поместим на машину с приложением. Его задачей будет подключиться по ssh к серверу, где у нас находится кэширующий nginx и удалить все файлы кэша, указанные в сформированном файле из шага 1;
Шаг 1. Формирование файла с путями до кэша.
Обратите внимание, что в переменной “$urls” содержатся url закэшированных страниц, уже в формате “proxy_cache_key”, указанном в конфиге nginx. Url выступает неким тегом для выводимых сущностей на странице. Например, можно создать обычную таблицу в бд, где каждый сущности будет сопоставлена конкретная страница, на которой она выводится. Тогда при изменении каких-либо данных мы можем сделать выборку по таблице и удалить кэш всех необходимых нам страниц.
Шаг 2. Подключение на кэширующий сервер и удаление файлов кэша.
Приведенные примеры несут ознакомительный характер, не стоит использовать их в production. В примерах опущены проверки входных параметров и ограничения команд. Одна из проблем с которой можно столкнутся — это ограничение длины аргумента команды “rm”. При тестировании в dev окружении на небольших объемах это можно легко упустить, а в production получить ошибку “rm: Argument list too long”.
Кэширование персонализированных блоков
Давайте подведем итог, что нам удалось сделать:
- снизили нагрузку на бэкенд;
- научились управлять кэшированием;
- научились сбрасывать кэш в любой момент времени.
Нужно рассмотреть альтернативную подгрузку таких частей страницы. Как всегда это можно сделать множеством способов, например после загрузки страницы отправлять ajax запрос, а на месте персонального контента отображать лоадер. Другим способом, который мы как раз сегодня и рассмотрим, будет использование ssi тегов. Давайте вначале разберемся что из себя представляет SSI, а затем, как мы можем его использовать в связке с nginx кэшем.
Что такое SSI и как он работает
SSI (Server-Side Includes, включения на стороне сервера) — это некий набор команд, встраиваемых в html страницу, указывающие серверу, что нужно сделать.
Вот некоторый перечень таких команд (директив):
• if/elif/else/endif — Оператор ветвления;
• echo — Выводит значения переменных;
• include — Позволяет вставлять содержимое другого файла в документ.
Как раз о последней директиве и пойдет речь. Директива include имеет два параметра:
• file — Указывает путь к файлу на сервере. Относительно текущей директории;
• virtual — Указывает виртуальный путь к документу на сервере.
Нас интересует параметр “virtual”, так как указывать полный путь до файла на сервере не всегда удобно, либо в случае распределенной архитектуры файла на сервере попросту нет. Пример директивы:
Для того, чтобы nginx начал обрабатывать ssi вставки, необходимо модифицировать location следующим образом:
Теперь все запросы, обрабатываемые location “/”, будут иметь возможность выполнять ssi вставки.
Как же во всей этой схеме будет проходить наш запрос?
- клиент запрашивает страницу;
- Nginx проксирует запрос на бэкенд;
- бэкенд отдает страницу с ssi вставками;
- результат сохраняется в кэш;
- Nginx “дозапрашивает” недостающие блоки;
- итоговая страница отправляется клиенту.
Избавляемся от постоянных запросов к бэкенду через ssi
В переменной $memcache_key мы указали ключ, по которому nginx попробует получить данные из memcache. Параметры подключения к серверу memcache задаются в директиве “memcached_pass”. Подключение можно указать несколькими способами:
• IP адрес и порт;
Если nginx удалось получить ответ от сервера кэша, то он отдает его клиенту. В случае когда данных в кэше нет, запрос будет передан на бэкенд через “@fallback”. Эта небольшая настройка memcached модуля под nginx поможет нам сократить количество проходящих запросов на бэкенд от ssi вставок.
Надеемся, эта статья была полезна и нам удалось показать один из способов оптимизации нагрузки на сервер, рассмотреть базовые принципы настройки nginx кэширования и закрыть возникающие проблемы при его использовании.
Давно минули те старые добрые времена, когда сайты были сделаны на голом HTML и их страницы весили несколько десятков килобайт. А интернет был на dial-up.
Рассмотрим метод борьбы с этой проблемой посредством вебсервера Nginx. Суть в том, что мы сделаем 2 вещи — сожмём все статические файлы (скрипты, файлы стилей) посредством gzip, и закэшируем их вместе с картинками в кэше браузера посетителя, чтобы они каждый раз не загружались с сайта, а брались прямо из кэша на компьютере посетителя сайта.
Все настройки и команды далее идут для сервера с Centos, однако настройка серверов с другими системами мало чем отличается.
Настройка сжатия данных посредством Nginx.
Открываем файл конфигурации Nginx, расположенный по адресу /etc/nginx/nginx.conf
Настройка кэширования статических файлов в кэше браузера пользователя, посредством Nginx.
В том же файле /etc/nginx/nginx.conf спускаемся ниже, находим конструкцию server для нужного сайта и дописываем туда:
где expires 7d — это количество дней, сколько кэш статических файлов должен храниться на компьютере пользователя. Если вы не вносите правки в css, js, файлы своего сайта и не меняете картинки, то имеет смысл этот параметр увеличить, вплоть до нескольких месяцев или даже до года.
Для наглядности приводим участок секции server из сервера, в котором Nginx был установлен стандартными средствами панели ISPmanager:
А теперь мы добавим сюда expires 7d, теперь это будет выглядеть вот так:
Перезагружаем Nginx командой:
Заходим на свой сайт и радуемся, он теперь стал загружаться в несколько раз быстрее. А вес страниц сайта снизился с нескольких мегабайт до пары десятков килобайт!
Данная статья будет полезна для владельцев виртуальных и выделенных серверов, так как у пользователей виртуального хостинга нет доступа к редактированию конфигурации Nginx. Однако клиенты виртуального хостинга, предлагаемого нашей организацией всегда могут обратиться в службу поддержки, и наши системные администраторы внесут необходимые настройки для вашего сайта.
Nginx умеет кэшировать запросы самостоятельно. Преимущества использования Nginx cache в его простоте по сравнению с Varnish.
Что кешировать?
Суть серверного кеширования в том, чтобы не генерировать постоянно одни и те же скрипты (например, ленту постов WordPress), что может иногда занимать целые секунды. Вместо этого, приложение генерирует страницу один раз, и результат сохраняется в память. Когда посетитель запросит ту же страницу второй раз,
генерации уже не будет, а клиент получит сохраненную в памяти версию. Раз в какое-то время (называемое ttl), эта сохраненная версия будет удаляться и генерироваться новая, чтобы поддерживать актуальность данных.
Почти на всех сайтах можно кэшировать страницы для неавторизованных пользователей. Хорошо подойдет для сайтов с контентом, который доступен публично.
Включение кеширования в Nginx
Устанавливаем размер кеша в 1G, сохранять его будем в папку
Не забываем создать папку для кеша.
Настройка хостов
Чтобы кеширование заработало, мы должны создать новый хост, который будет слушать 80 порт. А основной хост перенести на какой-то другой порт (например, 81). Кеширующий хост будет посылать запросы на основной либо отдавать данные из кеша.
Каждая страница будет сохраняться в кеш на 1 час
Обычный конфиг только на 81 порту
Cookies и персонализация
Многие сайты используют различные персональные блоки на страницах. Технология SSI позволяет реализовать продвинутое кеширование в случаях большого количество персонализированных блоков. В простом случае, мы можем просто отключать кеш, если у пользователя установлены какие-то Cookies.
Имеет смысл также включить кеширование ошибочных запросов на какое-то короткое время. Это позволит избежать частых повторных попыток обратиться к неработающей части сайта.
Кеширование fastcgi
Установим максимальный размер кеша в 1G
Не забываем создать папку
В конфигурации основного хоста, добавляем правила кеширования:
В данном случае мы будем кешировать ответы с кодом 200 на 60 минут
Самое важное
Пользуйтесь преимуществами кеширования. Довольно просто в настройке, зато может дать десятикратное ускорение сайта и экономию ресурсов.
Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.
Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
Откликнуться на вакансию можно здесь .
Как перезапустить nginx после обновления конфигурации
Включение и использование log-файлов для проверки работы Nginx
Как и зачем используется заголовок Cache-control
Уменьшение размера картинок при сохранении качества
Что такое Etag и как его настроить в Nginx
301 redirect в Nginx'e
Причины и методы исправления ошибки Gateway Timeout, Nginx
Как настроить Nginx на максимальную эффективность
Архитектурные принципы высоконагруженных приложений
Основы оптимизации работы Web сервера
Как использовать try_files в настройках Nginx'a
Где находится nginx.conf и пример настроек
Работа приложения с несколькими бэкендами при помощи Nginx
Как пофиксить ошибку "110: connection timed out" while reading response header from upstream
Причины возникновения ошибки Ошибка 502 bad gateway в Nginx и методы исправления
Примеры применения Javascript в Nginx'e
Как решить ошибку upstream sent too big header while reading response header from upstream в Nginx
Читайте также: