Фил Карлтон однажды сказал: «Есть только две трудные вещи в компьютерных науках: кэш недействительным и именования вещи». Эта статья о труднее из этих двух: кэш недействительным. Она направлена на читателей, которые уже работают с Varnish Cache. Чтобы узнать больше об этом, вы найдете справочную информацию в «Ускорить свой мобильный сайт с варня«.
10 микросекунд (или 250 миллисекунд): Вот в чем разница между доставкой кэша и доставкой промаха кэша. Как часто вы получаете последний будет зависеть от эффективности кэша — это известно как «хит скорость». Промах кэша зависит от двух факторов: объема трафика и среднего времени для жизни (TTL), который представляет собой число, указывающее, как долго кэш может хранить объект. Как системные администраторы и разработчики, мы не можем сделать много о трафике, но мы можем влиять на TTL.
Дальнейшее чтение на SmashingMag:
- Управление кэшом: использование стороны края включает в лак
- Ускорьте свой мобильный веб-сайт с помощью лака
- HTTPS Везде с Nginx, лак и Apache
- Взгляд на современный wordpress сервер астек
Однако, чтобы иметь высокий TTL, мы должны быть в состоянии недействительнымобъектов из кэша, так что мы избегаем обслуживания несвежего содержимого. С Лак Кэш, Есть множество способов сделать это. Мы рассмотрим наиболее распространенные способы и способы их развертывания.
Лак делает много других вещей, а также, но его кэширования услуги являются наиболее популярными. Кэши ускоряют web-службы, обслуживая кэшированное статическое содержимое. Когда Лак кэш доставляет кэш хит, он обычно просто сбрасывает кусок памяти в гнездо. Лаковый кэш настолько быстр, что на современном оборудовании мы измеряем время отклика в микросекундах!
Кэшинг не всегда так просто, как мы думаем; несколько gotchas и проблемы могут занять довольно много нашего времени, чтобы освоить. (Изображениякредитов)
При использовании кэша необходимо знать, когда выселить содержимое из кэша. Если у вас нет возможности выселить содержимое, то вы будете полагаться на кэш, чтобы тайм-аут объекта после заданного периода времени. Это один из методов, но едва ли самое оптимальное решение. Лучше всего было бы позволить Лак Кэш держать объект в памяти навсегда (в основном), а затем сказать объекту, когда обновить. Давайте вспомним, как этого достичь.
HTTP Очистка
HTTP Очистка является наиболее простым из этих методов. Вместо того, чтобы отправлять GET /url в варниш, вы бы отправить PURGE /url . Затем лак выбросит этот объект из кэша. Добавьте список управления доступом в Varnish, чтобы не каждый мог очистить объекты от кэша; кроме этого, хотя, вы дома бесплатно.
acl purge {
"localhost";
"192.168.55.0"/24;
}
sub vcl_recv {
# allow PURGE from localhost and 192.168.55...
if (req.request == "PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
return (lookup);
}
}
sub vcl_hit {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
Недостатки очистки
ОЧИСТКа HTTP не соответствует, когда часть содержимого имеет сложное отношение к URL-адресам, на которые он появляется. Например, новостная статья может отображаться на нескольких URL-адресах. В статье может быть представление рабочего стола и мобильное представление, и она может отображаться на странице раздела и на главной странице. Таким образом, вам придется либо получить систему управления контентом, чтобы отслеживать все эти проявления или пусть Лак сделать это за вас. Чтобы Лакьш сделать это, вы бы использовать запреты, которые мы получим в настоящее время.
Запреты
Запрет является особенностью лака и тот, который часто неправильно. Это позволяет запретить Лак от обслуживания определенного содержания в памяти, заставляя Лак принести новые версии этих страниц.
Интересный аспект заключается в том, как вы указать, какие страницы запретить. Лак имеет язык, который обеспечивает довольно много гибкости. Вы могли бы сказать, Лак запретить, давая запрет команды в интерфейсе командной строки, как правило, подключение к нему с varnishadm . Вы также можете сделать это через язык конфигурации Varnish (VCL), который обеспечивает простой способ реализации HTTP-запрещения.
Начнем с примера. Предположим, что мы должны очистить наш сайт от всех изображений.
> ban obj.http.content-type ~ “^image/”
Результатом этого является то, что для всех объектов в памяти, заголовок ответа HTTP Content-Type будет соответствовать регулярному выражению, ^image/ которое немедленно аннулируется.
Вот что происходит в Варнише. Во-первых, запрет команды ставит запрет на «запрет список». Когда эта команда находится в списке запретов, каждый хит кэша, который служит объекту старше самого запрета, начнет смотреть на список запретов и сравнивать объект с запретами в списке. Если объект совпадает, то Лак убивает его и получает более новый. Если объект не совпадает, то Varnish сделает замечание о нем, чтобы он не проверял снова.
Давайте опираться на наш пример. Теперь мы будем запрещать только изображения, которые размещены где-то в /feature URL. Обратите внимание на логического «и» оператора, && .
> ban obj.http.content-type ~ “^image/” && req.url ~ “^/feature”
Вы заметите, что он говорит obj.http.content-type и req.url . В первой части запрета мы имеем в виду атрибут объекта, хранящегося в варнесе. В последнем мы ссылаемся на часть запроса на объект. Это может быть немного нетрадиционным, но на самом деле можно использовать атрибуты в запросе для признания объектов недействительными в кэше. Теперь, req.url обычно не хранится в объекте, так что ссылаясь на запрос является единственное, что мы можем сделать здесь. Вы можете использовать это, чтобы делать сумасшедшие вещи,как запретить все, что запрашивается IP-адрес конкретного клиента, или запретить все, что запрашивается браузером Chromium. Поскольку эти запросы поражают Varnish, объекты аннулируются и обновляются с исходного сервера.
Выдача запретов, зависят от запроса, открывает некоторые интересные возможности. Тем не менее, есть один недостаток в этом процессе: очень длинный список запретов может замедлить доставку контента.
Существует рабочая нить, возложенная на задачу сокращения списка запретов, «запрет lurker». Запрет lurker пытается соответствовать запрету в отношении применимых объектов. Когда запрет был сопоставлен со всеми объектами, более старыми, он отбрасывается.
Как запрет lurker итерирует через запреты, он не имеет запрос HTTP, что он пытается служить. Таким образом, любые запреты, которые полагаются на данные из запроса не могут быть проверены запрет lurker. Чтобы сохранить запрет производительности вверх, то, мы рекомендуем не использовать данные запроса в запретах. Если вам нужно запретить что-то, что обычно находится в запросе, например URL, вы можете скопировать данные из запроса на объект vcl_fetch в, как это:
set beresp.http.x-url = req.url;
Теперь вы сможете использовать запреты на obj.http.x-url . Помните, что объекты превращаются в то время, beresp obj когда они хранятся в кэше.
Метки Содержание для запретов
Запреты часто намного более эффективны, когда вы даете Лак немного помочь. Если объект имеет X-Article-id заголовок, то вам не нужно знать все URL-адреса, которые объект представлен как.
Для страниц, зависят от нескольких объектов, можно добавить заголовок системы управления X-depends-on контентом. Здесь можно перечислить объекты, которые должны вызвать обновление текущего документа. Чтобы взять наш новостной сайт снова, вы можете использовать это, чтобы перечислить все статьи, упомянутые на первой странице:
X-depends-on: 3483 4376 32095 28372
Естественно, тогда, если одна из статей изменится, вы выдали бы запрет, как это:
ban obj.http.x-depends-on ~ “D4376D”
Это потенциально очень мощный. Представьте себе, что база данных выдает эти запросы на недействительные с помощью триггеров, тем самым устраняя необходимость изменения промежуточного слоя. Опрятно, да?
Изящные кэш-недействительные
Представьте себе, очистка что-то от Varnish, а затем происхождения сервера, который должен был заменить содержимое внезапно выходит из строя. Вы только что выбросили свою единственную работоспособную копию содержимого. Что ты наделала?! Оказывается, что довольно много систем управления контентом аварии на регулярной основе.
В идеале мы хотели бы поместить объект в третье состояние – признать его недействительным при условии, что мы сможем получить новое содержимое. Это третье состояние существует в varnish: Оно вызвано «благодатью,» и оно использовано с TTL-основанными недействительными. После истечения срока действия объекта он хранится в памяти в случае сбоя сервера с обратного конца. Если Varnish не может говорить с задней части, то он проверяет, соответствуют ли какие-либо льготные объекты, и он служит те, а не.
Один модуль Varnish (или VMOD), softpurge названный, позволяет вычеркнуть объект, поставив его в состояние благодати. Использовать его просто. Просто замените PURGE VCL с VCL, который использует softpurge VMOD.
import softpurge;
sub vcl_hit {
if (req.method == "PURGE") {
softpurge.softpurge();
error 200 “Successful softpurge”;
}
}
sub vcl_miss {
if (req.method == "PURGE) {
softpurge.softpurge();
error 200 "Successful softpurge";
}
}
Распространение событий, вносимых кэша,
Все перечисленные выше методы описывают процесс признания содержимого на одном сервере кэша недействительным. Большинство серьезных конфигураций будет иметь более одного сервера Varnish. Если у вас есть два, которые должны дать достаточно oomph для большинства веб-сайтов, то вы хотели бы выдать одно событие недействительным для каждого сервера. Однако, если у вас есть 20 или 30 серверов Varnish, то вы действительно не хотели бы увязнуть приложение, имея его цикл через огромный список серверов.
Вместо этого, вы хотите, чтобы одна конечная точка API, к которой вы можете отправить ваши чистки,имея его распространять событие недействительным для всех ваших серверов Varnish. Для справки, вот очень простая служба признания недействительным, написанная в оболочке скрипта. Он будет слушать на порт 2000 и недействительными URL-адреса на три различных серверов alfa (, beta и ) с gamma помощью cURL.
nc -l 2000 | while true
do read url
for srv in “alfa” “beta” “gamma”
do curl -m 2 -x $srv -X PURGE $url
done
done
Это может быть не подходит для производства, потому что обработка ошибок оставляет желать лучшего!
Кэш-недействительность почти так же важна, как и кэширование. Таким образом, наличие разумной стратегии для признания содержимого имеет решающее значение для поддержания высокой производительности и с высоким коэффициентом кэш-хит. Если вы поддерживаете высокую скорость попадания, то вам нужно меньше серверов и будет иметь более счастливых пользователей и, вероятно, меньше времени простоя. При этом, вы, надеюсь, более комфортно использовать инструменты, как эти, чтобы получить устаревший контент из кэша.
Источник: smashingmagazine.com
