Proxycache ошибка загрузки кэша прокси сервера
Как использовать proxy_cache
Добавьте следующий код в соответствующий файл конфигурации сервера nginx vhost:
proxy_cache_valid 200 206 304 301 302 10d;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Введение в элемент конфигурации:
Proxy_cache tmp-test использует соответствующую конфигурацию кеша с именем tmp-test
proxy_cache_key $ uri Определяет уникальный ключ кеша и обращается к хешу через уникальный ключ
proxy_pass относится к пути пересылки после прокси, обратите внимание, является ли последний /
На этом этапе самая основная функция proxy_cache успешно настроена. Когда uri успешно совпадает с местоположением, proxy_cache вступит в силу.
Задайте вопрос:
На этом этапе мы завершили самую базовую настройку proxy_cache и введение в процесс доступа, но самая базовая конфигурация часто не может удовлетворить потребности нашего бизнеса. Мы часто задаем следующие вопросы и требования:
- Необходимо активно очищать файлы кеша
- Путь записи - диск. Что делать, если диск заполнен?
- Как сделать так, чтобы исходный сайт поддерживал возобновляемую передачу и стратегию кэширования возобновляемой передачи
- Если запрашивающая сторона запрашивает запрос диапазона (сегментированная загрузка) для большого ресурса и того же URI, как отличить запрос?
- Вам также необходимо сообщить запрашивающей стороне время истечения срока действия ресурса.
- Журнал статистики, как настроить поля попаданий и промахов и как вести статистику?
Столкнувшись с вышеуказанными вопросами, мы решаем их по очереди.
Мемоизация функций
Сейчас поговорим об оптимизации производительности серверного приложения за счёт мемоизации. Это — разновидность кэширования, применяемая для оптимизации работы с ресурсоёмкими функциями. Данная техника позволяет выполнять полный цикл вычислений для определённого набора входных данных лишь один раз, а при следующих обращениях к функции с теми же входными данными сразу выдавать найденный ранее результат. Мемоизация реализуется посредством так называемых «таблиц поиска» (lookup table), хранящих ключи и значения. Ключи соответствуют входным данным функции, значения — результатам, которые возвращает функция при передаче ей этих входных данных.
Мемоизация функции с помощью таблицы поиска
Мемоизация — это обычный приём, используемый для повышения производительности программ. Однако он может быть не особенно полезным при работе с ресурсоёмкими функциями, которые вызываются редко, или с функциями, которые, и без мемоизации, работают достаточно быстро.
Что такое SSI и как он работает
SSI (Server-Side Includes, включения на стороне сервера) — это некий набор команд, встраиваемых в html страницу, указывающие серверу, что нужно сделать.
Вот некоторый перечень таких команд (директив):
• if/elif/else/endif — Оператор ветвления;
• echo — Выводит значения переменных;
• include — Позволяет вставлять содержимое другого файла в документ.
Как раз о последней директиве и пойдет речь. Директива include имеет два параметра:
• file — Указывает путь к файлу на сервере. Относительно текущей директории;
• virtual — Указывает виртуальный путь к документу на сервере.
Нас интересует параметр “virtual”, так как указывать полный путь до файла на сервере не всегда удобно, либо в случае распределенной архитектуры файла на сервере попросту нет. Пример директивы:
Для того, чтобы nginx начал обрабатывать ssi вставки, необходимо модифицировать location следующим образом:
Теперь все запросы, обрабатываемые location “/”, будут иметь возможность выполнять ssi вставки.
Как же во всей этой схеме будет проходить наш запрос?
- клиент запрашивает страницу;
- Nginx проксирует запрос на бэкенд;
- бэкенд отдает страницу с ssi вставками;
- результат сохраняется в кэш;
- Nginx “дозапрашивает” недостающие блоки;
- итоговая страница отправляется клиенту.
Как настроить модуль proxy_cache
Добавьте следующий код в файл nginx.conf:
proxy_cache_path/data/nginx/tmp-test levels=1:2 keys_zone=tmp-test:100m inactive=7d max_size=1000g;
proxy_cache_path Путь к кеш-файлу
Уровни Устанавливает уровень каталога файлов кэша; уровни = 1: 2 указывает на два уровня каталога.
keys_zone Установить имя кеша и размер разделяемой памяти
неактивно Удаляется, если никто не посещает в течение указанного времени
max_size Максимальное пространство кэша. Если пространство кэша заполнено, ресурс с наибольшим временем кеширования будет перезаписан по умолчанию.
После завершения настройки перезапустите nginx, если об ошибках не сообщается, настроенный proxy_cache вступит в силу
Проверьте каталог proxy_cache_path / data / nginx /,
Вы обнаружите, что создана папка tmp-test.
Кэш жёсткого диска
Жёсткие диски (HDD, Hard Disk Drive), применяемые для постоянного хранения данных — это, в сравнении с оперативной памятью, предназначенной для кратковременного хранения информации, устройства довольно медленные. Однако надо отметить, что скорость постоянных хранилищ информации увеличивается благодаря распространению твердотельных накопителей (SSD, Solid State Drive).
В системах долговременного хранения информации кэш диска (его ещё называют буфером диска или кэширующим буфером) — это встроенная в жёсткий диск память, которая играет роль буфера между процессором и физическим жёстким диском.
Кэш жёсткого диска
Дисковые кэши работают, исходя из предположения, что когда на диск что-то пишут, или с него что-то читают, есть вероятность того, что в ближайшем будущем к этим данным будут обращаться снова.
Простой веб-сервер
Теперь, когда мы обсудили роль кэширования в базовых механизмах компьютерных систем, рассмотрим пример, иллюстрирующий применение концепций кэширования при взаимодействии клиента, представленного веб-браузером, и сервера, который, реагируя на запросы клиента, отправляет ему некие данные. В самом начале у нас имеется простой веб-сервер, который, отвечая на запрос клиента, считывает данные с жёсткого диска. При этом представим, что между клиентом и сервером нет никаких особых систем кэширования. Вот как это выглядит.
Простой веб-сервер
При работе вышеописанной системы, когда клиент обращается напрямую к серверу, а тот, самостоятельно обрабатывая запрос, читает данные с жёсткого диска и отправляет клиенту, без кэша всё-таки не обходится, так как при работе с диском будет задействован его буфер.
При первом запросе жёсткий диск проверит кэш, в котором, в данном случае, ничего не будет, что приведёт к так называемому «промаху кэша». Затем данные считаются с самого диска и попадут в его кэш, что соответствует предположению, касающемуся того, что эти данные могут понадобиться снова.
При последующих запросах, направленных на получение тех же данных, поиск в кэше окажется успешным, это — так называемое «попадание кэша». Данные в ответ на запрос будут поступать из дискового буфера до тех пор, пока они не будут перезаписаны, что, при повторном обращении к тем же данным, приведёт к промаху кэша.
Возможные проблемы при кэшировании страниц
Следующая задача, с которой придется столкнуться — это управление кэшированием. Конечно можно установить незначительное время кэша в 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”.
Что такое 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”.
▍Веб-ускорители
Веб-ускоритель (web accelerator) — это прокси-сервер, который уменьшает время доступа к сайту. Он делает это, заранее запрашивая у сервера документы, которые, вероятнее всего, понадобятся клиентам в ближайшем будущем. Подобные серверы, кроме того, могут сжимать документы, ускорять выполнение операций шифрования, уменьшать качество и размер изображений, и так далее.
О быстродействии жёстких дисков и оперативной памяти
Разница между временным хранением данных в оперативной памяти и постоянным хранением на жёстком диске проявляется в скорости работы с информацией, в стоимости носителей и в близости их к процессору.
Время отклика оперативной памяти составляет десятки наносекунд, в то время как жёсткому диску нужны десятки миллисекунд. Разница в быстродействии дисков и памяти составляет шесть порядков!
Одна миллисекунда равна миллиону наносекунд
▍Шлюзы
Шлюз (gateway) — это прокси-сервер, который перенаправляет входящие запросы или исходящие ответы, не модифицируя их. Такие прокси-серверы ещё называют туннелирующими прокси (tunneling proxy), веб-прокси (web proxy), прокси (proxy), или прокси уровня приложения (application level proxy). Эти прокси-серверы обычно совместно используются, например, всеми клиентами, находящимися за одним и тем же файрволом, что делает их хорошо подходящими для кэширования запросов.
Вопрос 1: заранее очистите кеш
Принять: модуль nginx proxy_cache_purge, который появляется в паре с proxy_cache, а функция как раз наоборот.
Метод разработки: в nginx запустите другой сервер и, когда вам нужно очистить кеш ресурсов ответа, обратитесь к этому серверу на локальном компьютере.
Посетите 127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt, чтобы очистить файл кеша этого ресурса.
allow 127.0.0.1; // Разрешить только локальный доступ
deny all; // Запрещаем все остальные ip
proxy_cache_purge tmp-test $ uri; // Очистить кеш
proxy_cache_purge: модуль очистки кеша
tmp-test: указанная key_zone
$ uri: указанные параметры для генерации ключа
Процесс очистки кеша proxy_cache_purge, как показано на рисунке:
1.1 сценарии использования
Предположим, у меня есть такой сценарийUserWhiteReadService.getUserWhiteByAppAndWhiteCodeЕсли вы хотите сначала получить данные из кэша, результат будет пустым, затем перейдите к собственному методу и поместите результат, возвращенный собственным методом, в кэш. Традиционный подход заключается в написании набора кода, который выбирает кэш, а затем определяет, что он пуст. Если есть больше методов, каждый метод, который должен быть кэширован, должен повторить вышеописанное кодирование. В сочетании с этим сценарием, какие преимущества мы можем получить от использования taobao-pamirs-proxycache. Из следующего кода кэшированный код удаляется из бизнес-кода. Вам нужно только настроить XML для достижения цели традиционных практик. Управление более централизовано.
Конфигурация кэша и метода очистки biz-cache.xml
конфигурация кеша base-cache.xml
Модуль загрузки информации о конфигурации кэша
модуль генерации beanProxy (объектный прокси-объект)
Модуль генерации CacheProxy (кэш-прокси)
Модуль мониторинга журналов (не рассматривается в этой статье)
3.1.2 Адаптация обработки кэша к сборке CacheProxy
CacheProxy: содержит ключ адаптера, тип кеша (например, тайный кеш или локальный кэш карты), объектный компонент и метод, соответствующий кешу, пространство кеша (необходимое для тира) и т. Д.
ICache: это основной интерфейс для кеширования. Предоставляет общие методы, такие как получить, положить и очистить. В настоящее время поддерживает два типа кеша: эфир и карта.
CacheManagerHandle: Этот класс обработки кэша является очень важным: он реализует интерфейс AbstractAutoProxyCreator, переопределяет метод getAdvicesAndAdvisorsForBean и реализует собственный аспект AOP CacheManagerAdvisor. CacheManagerAdvisor использует перехватчик CacheManagerRoundAdvice CacheManagerRoundAdvice реализует метод invoke интерфейса MethodInterceptor для реализации доступа к кэшу и очистки аспектов кеша при доступе к целевому методу. В частности, посмотрите на следующий исходный код:
Метод invoke, переписанный CacheManagerRoundAdvice: Intercept перед обращением к целевому методу. Если это операция, которая обращается к кешу, имплантируется аспект прокси-сервера кеша, который преимущественно берется из результата кеша. Если он недоступен, данные берутся из собственного метода и помещают в кеш. Если это операция очистки кэша, после обращения к собственному методу данные кэша истории собственного метода очищаются.
Нативные методы, не перехватывать исключения в случайном порядке или генерировать исключения вручную после их перехвата. Поскольку используется инструмент кэширования, пока этот метод вызывается без исключения, результат встроенного метода (не исключая результат исключения) будет кэшироваться платформой. Я помню, как один раз во время упражнения на отключение сети, потому что отключение вызвало сбой БД подключения, информация об исключении все еще была поймана мной, и результатом стала трагедия. Когда приложение возобновляет работу, вызовите этот метод еще раз, и возвращаемый результат всегда будет исключением ~
Напиши в конце
Мой новый блог
Блоги CSDN часто не открываются. Старые блоги сохраняются некоторое время ~~
Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2.
Существует две основные причины, по которым используется веб-кэш:
1. Уменьшение времени ожидания — так как данные по запросу берутся из кэша (который располагается “ближе” к клиенту), требуется меньше времени для получения и отображения контента на стороне клиента. Это делает Веб более отзывчивым (прим. переводчика — “отзывчивым” в контексте быстроты реакции на запрос, а не эмоционально).
2. Снижение сетевого трафика — повторное использование контента снижает объем данных, передаваемых клиенту. Это, в свою очередь, экономит деньги, если клиент платит за трафик, и сохраняет низкими и более гибкими требования к пропускной способности канала.
Виды веб-кэшей
Кэш браузера (Browser cache)
Если вы изучите окно настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вы, вероятно, заметите параметр настройки «Кэш». Эта опция позволяет выделить область жесткого диска на вашем компьютере для хранения просмотренного ранее контента. Кэш браузера работает согласно довольно простым правилам. Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).
Прокси-кэш (Proxy cache)
Прокси-кэш работает по аналогичному принципу, но в гораздо большем масштабе. Прокси обслуживают сотни или тысячи пользователей; большие корпорации и интернет-провайдеры часто настраивают их на своих файрволах или используют как отдельные устройства (intermediaries).
Поскольку прокси не являются частью клиента или исходного сервера, но при этом обращены в сеть, запросы должны быть к ним как-то переадресованы. Одним из способов является использование настроек браузера для того, чтобы вручную указать ему к какому прокси обращаться; другой способ — использование перехвата (interception proxy). В этом случае прокси обрабатывают веб-запросы, перенаправленные к ним сетью, так, что клиенту нет нужды настраивать их или даже знать об их существовании.
Прокси-кэши являются своего рода общей кэш-памятью (shared cache): вместо обслуживания одного человека, они работают с большим числом пользователей и поэтому очень хороши в сокращении времени ожидания и сетевого трафика. В основном, из-за того, что популярный контент запрашивается много раз.
Кэш-шлюз (Gateway Cache)
Также известные как “реверсивные прокси-кэши” (reverse proxy cache) или “суррогаты” (surrogate cache) шлюзы тоже являются посредниками, но вместо того, чтобы использоваться системными администраторами для сохранения пропускной способности канала, они (шлюзы) обычно используются веб-мастерами для того, чтобы сделать их сайты более масштабируемыми, надежными и эффективными.
Запросы могут быть перенаправлены на шлюзы рядом методов, но обычно используется балансировщик нагрузки в той или иной форме.
Сети доставки контента (content delivery networks, CDN) распространяют шлюзы по всему интернету (или некоторой его части) и отдают кэшированный контент заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.
Это учебное пособие преимущественно сфокусировано на браузерных кэшах и прокси, но некоторая информация подходит также и тем, кому интересны шлюзы.
Почему я должен им пользоваться
Кэширование является одной из наиболее неправильно понятых технологий в интернете. Веб-мастера, в частности, боятся потерять контроль над их сайтом, потому что прокси могут “скрыть” их пользователей, сделав сложным наблюдение посещаемости.
К несчастью для них (веб-мастеров), даже если бы веб-кэша не существовало, есть слишком много переменных в интернете, чтобы гарантировать, что владельцы сайтов будут в состоянии получить точную картину того, как пользователи обращаются с сайтом. Если это является для вас большой проблемой, данное руководство научит вас как получить необходимую статистику, не делая ваш сайт “кэшененавистником”.
Другой проблемой является то, что кэш может хранить содержимое, которое устарело или просрочено.
С другой стороны, если вы ответственно подходите к проектированию вашего веб-сайта, кэш может помочь с более быстрой загрузкой и сохранением нагрузки на сервер и интернет-соединение в рамках допустимого. Разница может быть впечатляющей: загрузка сайта, не работающего с кэшем, может потребовать нескольких секунд; в то время как преимущества использования кэширования могут сделать её кажущейся мгновенной. Пользователи по достоинству оценят малое время загрузки сайта и, возможно, будут посещать его чаще.
Подумайте об этом в таком ключе: многие крупные интернет-компании тратят миллионы долларов на настройку ферм серверов по всему миру для репликации контента для того, чтобы ускорить, как только можно, доступ к данным для своих пользователей. Кэш делает то же самое для вас и он гораздо ближе к конечному пользователю.
CDN, с этой точки зрения, являются интересной разработкой, потому что, в отличие от многих прокси-кэшей, их шлюзы приведены в соответствие с интересами кэшируемого веб-сайта. Тем не менее, даже тогда, когда вы используете CDN, вы все равно должны учитывать, что там будет прокси и последующее кэширование в браузере.
Резюмируя, прокси и кэш браузера будут использоваться, нравится вам это или нет. Помните, если вы не настроите ваш сайт для корректного кэширования, он будет использовать настройки кэша по-умолчанию.
Как работает веб-кэш
Вообще говоря, это самые общие правила (не волнуйтесь, если вы не понимаете детали, они будут объяснены ниже):
Свежесть (freshness) и валидация (validation) являются наиболее важными способами, с помощью которых кэш работает с контентом. Свежий контент будет доступен мгновенно из кэша; валидное же содержимое избежит повторной отправки всех пакетов, если оно не было изменено.
В жизни каждого проекта настает время, когда сервер перестает отвечать требованиям SLA и буквально начинает захлебываться количеством пришедшего трафика. После чего начинается долгий процесс поиска узких мест, тяжелых запросов, неправильно созданных индексов, не кэшированных данных, либо наоборот, слишком часто обновляемых данных в кэше и других темных сторон проекта.
Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.
Но если вас не покидает чувство, что ваш сервер способен на большее, или есть магический параметр, ускоряющий работу сайта в 100 раз, то можно вспомнить о встроенной возможности nginx, позволяющей кэшировать ответы от бэкенда. Давайте разберем по порядку, что это, и как это может помочь увеличить количество обрабатываемых запросов сервером.
Кэширование персонализированных блоков
Давайте подведем итог, что нам удалось сделать:
- снизили нагрузку на бэкенд;
- научились управлять кэшированием;
- научились сбрасывать кэш в любой момент времени.
Нужно рассмотреть альтернативную подгрузку таких частей страницы. Как всегда это можно сделать множеством способов, например после загрузки страницы отправлять ajax запрос, а на месте персонального контента отображать лоадер. Другим способом, который мы как раз сегодня и рассмотрим, будет использование ssi тегов. Давайте вначале разберемся что из себя представляет SSI, а затем, как мы можем его использовать в связке с nginx кэшем.
Кэширование в браузере
Перед нами весьма полезная технология, которая даёт следующие преимущества всем участникам обмена данными:
- Улучшаются впечатления пользователя от работы с сайтом, так как ресурсы из локального кэша загружаются очень быстро. Во время получения ответа не входит время прохождения сигнала от клиента к серверу и обратно (RTT, Round Trip Time), так как запрос не уходит в сеть.
- Уменьшается нагрузка на серверное приложение и на другие серверные компоненты, ответственные за обработку запросов.
- Высвобождается некоторая часть сетевых ресурсов, которыми теперь могут воспользоваться другие пользователи интернета, экономятся средства на оплату трафика.
Кэширование в браузере
3.1.1 Построение ключа адаптера кеша
Принцип proxy_cache:
Принцип работы модуля proxy_cache показан на рисунке:
Избавляемся от постоянных запросов к бэкенду через ssi
В переменной $memcache_key мы указали ключ, по которому nginx попробует получить данные из memcache. Параметры подключения к серверу memcache задаются в директиве “memcached_pass”. Подключение можно указать несколькими способами:
• IP адрес и порт;
Если nginx удалось получить ответ от сервера кэша, то он отдает его клиенту. В случае когда данных в кэше нет, запрос будет передан на бэкенд через “@fallback”. Эта небольшая настройка memcached модуля под nginx поможет нам сократить количество проходящих запросов на бэкенд от ssi вставок.
Надеемся, эта статья была полезна и нам удалось показать один из способов оптимизации нагрузки на сервер, рассмотреть базовые принципы настройки nginx кэширования и закрыть возникающие проблемы при его использовании.
Ник Карник, автор материала, перевод которого мы сегодня публикуем, предлагает поговорить о роли кэширования в производительности веб-приложений, рассмотрев средства кэширования разных уровней, начиная с самого низкого. Он обращает особое внимание на то, где именно могут быть кэшированы данные, а не на то, как это происходит.
Мы полагаем, что понимание особенностей систем кэширования, каждая из которых вносит определённый вклад в скорость реакции приложений на внешние воздействия, расширит кругозор веб-разработчика и поможет ему в деле создания быстрых и надёжных систем.
Вопрос 2: Что делать, если кеш-файл заполнен диском?
Поскольку путь записи - это один каталог, можно записать только один диск. Диск скоро заполнится. Есть два способа решить эту проблему:
1. Будет ли несколько дисков использоваться как дисковый массив? Недостатком является то, что фактическое пространство для хранения уменьшается.
2. Используйте структуру каталогов proxy_cache_path с умом. Поскольку уровни = 1: 2, это приводит к двухуровневой структуре каталогов для файла кэша, а имя каталога каждого уровня генерируется хеш-функцией. как показано на картинке:
Всего имеется 16 * 16 * 16 = 4096 файловых каталогов. Создайте мягкую ссылку на каталог первого уровня и, соответственно, мягкую ссылку 0-f на указанный каталог диска, который вам нужен, как показано на рисунке:
С помощью метода мягкой цепочки понимается, что каталоги на разных дисках используются в качестве пути для фактического хранения данных, что решает проблему использования нескольких дисков и переполнения одного диска.
Итоги
В этом материале мы рассмотрели различные уровни кэширования данных, применяющиеся в процессе обмена информацией между клиентом и сервером. Веб-приложения не могут мгновенно реагировать на воздействия пользователя, что, в частности, связано, для действий, требующих обмена данными с серверами этих приложений, с необходимостью выполнения неких вычислений перед отправкой ответа. Во время, необходимое для передачи данных от сервера клиенту, входит и время, необходимое для поиска необходимых данных на диске, и сетевые задержки, и обработка очередей запросов, и механизмы регулирования полосы пропускания сетей, и многое другое. Если учесть, что всё это может происходить на множестве компьютеров, находящихся между клиентом и сервером, то можно говорить о том, что все эти задержки способны серьёзно увеличить время, необходимое для прихода запроса на сервер и получения клиентом ответа.
Правильно настроенная система кэширования способна значительно улучшить общую производительность сервера. Кэши сокращают задержки, неизбежно возникающие при передаче данных по сети, помогают экономить сетевой трафик, и, в результате, уменьшают время, необходимое для того, чтобы браузер вывел запрошенную у сервера веб-страницу.
Благодаря своей работе я занимаюсь вебкастингом, в котором для воспроизведения и загрузки видео используются некоторые технологии загрузки видео. Текущий основной подход на рынке для загрузки полного видео заключается в том, чтобы сначала нарезать весь видеопоток и сохранить его на файловом сервере, когда пользователю необходимо просмотреть воспроизводимое видео. Передайте видео обратно на исходный сервер, перейдите на файловый сервер, чтобы запросить фрагменты один за другим и вернуть их пользователю для воспроизведения.
Сегодня я сосредоточусь на настройке кэширования обратного сервера и разумных стратегиях кэширования.
В случае настройки кэша для обратного сервера подробно описывается полный набор механизмов конфигурации кеша, и его можно использовать в любых других сценариях конфигурации кеша.
Сегодняшнее объяснение разделено на четыре пункта:
- Какова работа сервера возврата к источнику
- Зачем нужно добавлять кеширование на исходный сервер
- Как настроить кеш
- Как настроить полный механизм кеширования для бизнес-сценариев
Кэширование баз данных
Усложним наш пример, добавим сюда базу данных. Запросы к базам данных могут быть медленными и требовать серьёзных системных ресурсов, так как серверу баз данных, для формирования ответа, нужно выполнять некие вычисления. Если запросы повторяются, кэширование их средствами базы данных поможет уменьшить время её отклика. Кроме того, кэширование полезно в ситуациях, когда несколько компьютеров работают с базой данных, выполняя одинаковые запросы.
Простой веб-сервер с базой данных
Большинство серверов баз данных по умолчанию настроены с учётом оптимальных параметров кэширования. Однако, существует множество настроек, которые могут быть модифицированы для того, чтобы подсистема баз данных лучше соответствовала особенностям конкретного приложения.
Ответы веб-сервера кэшируются в оперативной памяти. Кэш приложения может храниться либо локально, в памяти, либо на специальном кэширующем сервере, который использует базу данных, вроде Redis, которая хранит данные в оперативной памяти.
▍Обратные прокси-серверы
Обратный прокси-сервер (reverse proxy) — это обычно сервер, расположенный там же, где и веб-сервер, с которым он взаимодействует. Обратные прокси-серверы предназначены для предотвращения прямого доступа к серверам, расположенным в частных сетях. Обратные прокси используются для балансировки нагрузки между несколькими внутренними серверами, предоставляют возможности SSL-аутентификации или кэширования запросов. Такие прокси выполняют кэширование на стороне сервера, они помогают основным серверам в обработке большого количества запросов.
Кэширование и прокси-серверы
В компьютерных сетях прокси-серверы могут быть представлены специальным аппаратным обеспечением или соответствующими приложениями. Они играют роль посредников между клиентами и серверами, хранящими данные, которые этим клиентам требуются. Кэширование — это одна из задач, которую они решают. Рассмотрим различные виды прокси-серверов.
Анализ принципа реализации Taobao-Pamirs-Proxycache с открытым исходным кодом кэш-прокси фреймворк
taobao-pamirs-proxycache - это кэш-прокси с открытым исходным кодом, которая отделяет кеш-код от бизнес-кода. Пусть разработка сосредоточится на бизнесе кодирования, и кеш может быть достигнут с помощью конфигурации XML. Эта статья начинается с того, как использовать этот инструмент, чтобы дать всем понять ~, а затем анализирует принципы его реализации из исходного кода.
После добавления proxy_cache изменения в процессе запроса:
1. Первое посещение:
При первом посещении proxy_cache не нашел соответствующий файл кеша (отсутствует кеш MISS), поэтому при выполнении первого запроса proxy_cache сохранит кеш:
2. Сохраните кеш, как показано на рисунке:
3. При повторном обращении к тому же URL-адресу, когда тот же файл снова поступает на исходный сайт, proxy_cache найдет соответствующий ему файл кеша (ударит HIT кеша) и вернет его непосредственно запрашивающей стороне без выполнения программы PHP, как показано на рисунке:
Вопрос 3: Диапазон поддержки (возобновление точки останова)
После добавления прокси-сервера кеша запрос диапазона, инициированный клиентом, станет недействительным, как показано на следующем рисунке:
Причины, по которым параметр диапазона не может быть передан на следующий уровень, следующие:
▍Прямые прокси-серверы
Прямой прокси-сервер (forward proxy, часто такие серверы называют просто proxy server) обычно устанавливается на стороне клиента. Веб-браузер, который настроен на использование прямого прокси-сервера, будет отправлять исходящие запросы этому серверу. Затем эти запросы будут перенаправлены на целевой сервер, расположенный в интернете. Одно из преимуществ прямых прокси заключаются в том, что они защищают данные клиента (однако, если говорить об обеспечении анонимности в интернете, безопаснее будет пользоваться VPN).
Работа back-to-origin сервера:
Сервер обратного происхождения упоминается как исходная станция в следующем описании.
Как показано на рисунке, в процессе загрузки файла он проходит между CDN и файловым сервером в качестве концентратора загрузки.
Архитектура исходного сайта: исходный сайт - это архитектура веб-сервера nginx + php, как показано на рисунке:
Но если исходный сайт просто получает запрос, загружает ресурс и затем возвращается, обязательно возникнут следующие проблемы, которые не будут оптимизированы:
1. CDN может иметь многократное возвращение к источнику.
2. Множественные загрузки одного и того же ресурса исходным сайтом приведут к потере полосы пропускания сетевого трафика и ненужным затратам времени.
Следовательно, чтобы оптимизировать эти проблемы, необходимо создать слой кеша для исходного сайта. Стратегия кеширования использует модуль proxy_cache, который поставляется с nginx.
Процессорный кэш
Начнём наш разговор о кэшах с самого низкого уровня — с процессора. Кэш-память процессора — это очень быстрая память, которая играет роль буфера между процессором (CPU) и оперативной памятью (RAM). Кэш-память хранит данные и инструкции, к которым обращаются чаще всего, благодаря чему процессор может получать ко всему этому доступ практически мгновенно.
В процессорах имеется особая память, представленная регистрами процессора, которая обычно представляет собой небольшое хранилище информации, обеспечивающее крайне высокую скорость обмена данными. Регистры — это самая быстрая память, с которой может работать процессор, которая расположена максимально близко к остальным его механизмам и имеет небольшой объём. Иногда регистры называют кэшем нулевого уровня (L0 Cache, L — это сокращение от Layer).
У процессоров, кроме того, имеется доступ к ещё нескольким уровням кэш-памяти. Это — до четырёх уровней кэша, которые, соответственно, называются кэшами первого, второго, третьего, и четвёртого уровня (L0 — L4 Cache). То, к какому именно уровню относятся регистры процессора, в частности, будет ли это кэш нулевого или первого уровня, определяется архитектурой процессора и материнской платы. Кроме того, от архитектуры системы зависит то, где именно — на процессоре, или на материнской плате, физически расположена кэш-память разных уровней.
Структура памяти в некоторых новейших CPU
3.1 Диаграмма архитектуры загрузки информации о конфигурации кэша
Из приведенного выше рисунка и в сочетании с исходным кодом CacheManager является загрузочным входом инфраструктуры кэша. CacheManager имеет две ключевые детали реализации:
1. Метод инициализации init () определен, а loadConfig () реализован подклассом LocalConfigCacheManager. Это точка входа для загрузки информации о конфигурации кеша и сборки в компонент кеша.
2. Реализовал интерфейс ApplicationListener и переопределил метод прослушивания событий.
Метод initCache () в основном используется для создания ключа адаптации кеша, генерации «кеш-прокси» -CacheProxy, соответствующего всем кешируемым методам, и запланированной задачи очистки кеша. Каждая из вышеперечисленных деталей будет объяснена ниже.
▍Пограничное кэширование
Обратные прокси-серверы расположены близко к серверам. Существует и технология, при использовании которой кэширующие серверы располагаются как можно ближе к потребителям данных. Это — так называемое пограничное кэширование (edge caching), представленное сетями доставки контента (CDN, Content Delivery Network). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.
Прокси-серверы в инфраструктуре обмена данными между клиентом и сервером
Читайте также: