wizard varnish что это

Полировщик для веб-сайта. Знакомимся с кеширующим прокси Varnish

Содержание статьи

Немного о проекте

Varnish пред­став­ляет собой кеширу­ющий «обратный» (reverse) прок­си‑сер­вер и аксе­лера­тор HTTP. Прин­цип его работы в общем стан­дартен для такого клас­са прог­рамм. Он получа­ет зап­рос, обра­баты­вает его и сра­зу выда­ет ответ, если он при­сутс­тву­ет в кеше; если нет, то обра­щает­ся к веб‑сер­веру за резуль­татом. Ответ помеща­ется в кеш. Varnish написан с нуля для нор­веж­ской газеты Verdens Gang. Вер­сия 1.0 появи­лась в 2006 году, в 2014-м пред­став­лен релиз 4.0. Основной код дос­тупен под BSD-подоб­ной лицен­зии, но есть и ком­мерчес­кие модули.

Про­ект сра­зу прив­лек себе вни­мание весь­ма гром­кими заяв­лени­ями авто­ра, одно­го из раз­работ­чиков FreeBSD Пола‑Хен­нинга Кам­па (Poul-Henning Kamp) о том, что все (с намеком на Squid) сде­лано неп­равиль­но. И дей­стви­тель­но, Varnish выделя­ет сов­ремен­ный дизайн, эффектив­но исполь­зующий воз­можнос­ти сов­ремен­ных мно­гоп­роцес­сорных сис­тем (Sqiud научил­ся работать с SMP чуть поз­же с вер­сии 3.2). Мно­гопо­точ­ность реали­зова­на с помощью стан­дар­тных потоков POSIX, их количес­тво регули­рует­ся. Это одна из при­чин, почему Varnish не очень хорошо работа­ет в Windows. Каж­дый зап­рос обра­баты­вает­ся в отдель­ном потоке. При­чем с вер­сии 4.0 за получе­ние зап­роса от поль­зовате­ля и переда­чу зап­роса сер­веру отве­чают раз­ные потоки, что еще более повыси­ло про­изво­дитель­ность. Varnish под­держи­вает тех­нологию ESI (Edge Side Includes), поз­воля­ющую раз­бивать веб‑стра­ницу на час­ти и зап­рашивать их отдель­но. Кеш может хра­нить любую информа­цию. В ито­ге Varnish отлично под­ходит для кеширо­вания динами­чес­кого кон­тента.

Для хра­нения дан­ных (кеша, жур­налов опе­раций) исполь­зует­ся вир­туаль­ная память. Управле­нием того, что выг­ружа­ется на диск, занима­ется ОС. Здесь авто­ры Varnish спра­вед­ливо счи­тают, что раз­работ­чики ОС свое дело зна­ют, а дуб­лирова­ние толь­ко ухуд­шает про­изво­дитель­ность.

В отли­чие от Squid, который изна­чаль­но боль­ше ори­енти­ровал­ся на кеширо­вание кли­ент­ских зап­росов, Varnish был раз­работан и опти­мизи­рован имен­но в качес­тве уско­рите­ля HTTP и ничего дру­гого боль­ше не уме­ет. Мы не най­дем здесь под­дер­жку осталь­ных про­токо­лов (FTP, SMTP и про­чие), не уви­дим воз­можнос­ти пря­мого прок­си — кеширо­вания веб‑стра­ниц для эко­номии внеш­него тра­фика (Varnish «при­вязы­вает­ся» к бэкен­дам). Естес­твен­но, отли­чают­ся и воз­можнос­ти по кон­фигури­рова­нию.

Язык кон­фигура­ции Varnish Configuration Language (VCL) — динами­чес­кий, скрипт сам по себе по сути явля­ется отдель­ным пла­гином. Код тран­сли­рует­ся в С (мож­но сра­зу писать встра­иваемый код на С), пос­ле чего инс­трук­ции ком­пилиру­ются в биб­лиоте­ку и под­гру­жают­ся в память. Мож­но вно­сить изме­нения в кон­фигура­цию на лету. Инс­трук­ции в VCL поз­воля­ют кеширо­вать толь­ко опре­делен­ные зап­росы, сни­жая наг­рузку при генера­ции динами­чес­ких объ­ектов, бло­киро­вать дос­туп к опре­делен­ным катало­гам и скрип­там, под­менять заголов­ки и мно­гое дру­гое. Есть и механизм про­вер­ки работос­пособ­ности бэкен­дов (замер вре­мени отве­та, счет­чик неудач­ных про­верок и так далее), воз­можность переза­писи и перенап­равле­ния (rewrite) зап­росов. Вооб­ще, такой под­ход поз­воля­ет про­изво­дить с HTTP-тра­фиком прак­тичес­ки любые манипу­ляции, которые мож­но огра­ничить толь­ко собс­твен­ным вооб­ражени­ем. Под­держи­вает­ся балан­сиров­ка наг­рузки (round robin, random и DNS, Client IP). Воз­можнос­ти рас­ширя­ются при помощи модулей, называ­емых VMOD (Varnish MODules). Про­ект пре­дос­тавля­ет необ­ходимую докумен­тацию, поз­воля­ющую написать такой модуль самос­тоятель­но. Часть мо­дулей уже вклю­чены в стан­дар­тную пос­тавку, некото­рые дос­тупны в виде кон­цепта или находят­ся в раз­работ­ке.

Про­ект уже пре­дос­тавля­ет боль­шое количес­тво модулей

Се­год­ня Varnish исполь­зуют такие веб‑сер­висы, как Facebook, Twitter, Vimeo и Tumblr.

Установка и базовая настройка Varnish

Офи­циаль­но рекомен­дует­ся уста­нов­ка Varnish на сов­ремен­ных вер­сиях x64-бит­ных Linux, FreeBSD или Solaris. Пакеты мож­но най­ти в допол­нитель­ных репози­тори­ях (вро­де EPEL или Ubuntu Universe) боль­шинс­тва дис­три­бути­вов Linux и пор­тах *BSD-сис­тем. Сам про­ект пре­дос­тавля­ет репози­тории и под­робные инс­трук­ции для Red Hat, Debian, Ubuntu и FreeBSD. В боль­шинс­тве слу­чаев сле­дует исполь­зовать имен­но репози­торий раз­работ­чика, так как в нем находит­ся более све­жая вер­сия про­дук­та. Воз­можна работа и в Windows (через Cygwin), но опти­миза­ция под *nix-сис­темы не гаран­тиру­ет мак­сималь­ной про­изво­дитель­нос­ти резуль­тата. На сай­те дос­тупны две вер­сии Varnish — 3.x и 4.x, обе явля­ются ста­биль­ными, но под­дер­жка линей­ки 3.x будет прек­ращена в пер­вой полови­не 2015 года. Кста­ти, код дос­таточ­но хорошо написан, поэто­му исправ­лений вно­сит­ся мало (нап­ример, 3-я вет­ка, появив­шаяся в июне 2011-го, содер­жала все­го шесть вер­сий), мож­но не боять­ся исполь­зовать све­жие релизы. Стан­дар­тно Varnish ста­вит­ся перед веб‑сер­вером и кеширу­ет зап­росы. В наг­ружен­ных сис­темах иног­да исполь­зуют более слож­ный вари­ант, ког­да вна­чале зап­рос при­нима­ет лег­кий веб‑сер­вер (nginx, lighttpd), который уме­ет быс­тро отда­вать опре­делен­ные стра­ницы. При необ­ходимос­ти этот сер­вер через Varnish обра­щает­ся к основно­му HTTP-сер­веру, генери­рующе­му кон­тент. Varnish при наличии информа­ции в кеше отда­ет ее отту­да.

Для при­мера уста­новим Varnish в Ubuntu 14.04 LTS в качес­тве фрон­тенда Apache. В дру­гих дис­три­бути­вах отли­чия толь­ко в рас­положе­нии кон­фигура­цион­ных фай­лов и осо­бен­ностях пакет­ных сис­тем.

Вот, собс­твен­но, и все. Пос­ле уста­нов­ки Varnish стар­тует и что‑то там кеширу­ет. Зай­мем­ся кон­фигури­рова­нием. Уста­нов­ки парамет­ров запус­ка демона про­изво­дят­ся в фай­ле /etc/default/varnish. Пер­воначаль­но он скон­фигури­рован с некото­рыми парамет­рами. Если открыть файл, то уви­дим внут­ри три готовые нас­трой­ки: minimal, c VCL и advanced.

Файл /etc/default/varnish

По умол­чанию акти­виро­ван вто­рой режим. При этом сер­вер при­нима­ет под­клю­чения на порт 6081, для адми­нис­три­рова­ния исполь­зует­ся localhost:6082, а бэкенд опре­деля­ется в VCL. Для кеширо­вания выделя­ется 256 Мб памяти. Нас­тро­им так, что­бы Varnish слу­шал 80-й порт, кешируя зап­росы HTTP-сер­вера, рас­положен­ного на этой же машине. Ком­менти­руем нас­трой­ки вто­рого вари­анта и в качес­тве шаб­лона будем исполь­зовать advanced, как более наг­лядный.

Источник

Linuxoid

OpenSource forever

Знакомимся с кэширующим прокси Varnish

Обработка большого числа запросов может быть весьма тяжелой задачей забирающей ресурсы веб-сервера. Чтобы снять нагрузку используют фронтэнд в качестве которого может выступать легкие nginx/lighttpd или кэширующий прокси-сервер. Во втором качестве очень популярен Squid, он универсален, но не всегда оптимален. Но именно в этой задаче его более эффективно заменяет Varnish.

Немного о проекте

Varnish(varnish-cache.org) представляет собой кеширующий “обратный” (reverse) прокси-сервер и акселератор HTTP. Принцип его работы вообщем стандартен для такого класса программ. Он получает запрос, обрабатывает его и сразу выдает ответ если он присутствует в кэше, если нет то обращается к веб-серверу за результатом. Ответ помещается в кэш. Varnish написан с нуля для норвежской газеты Верден Gang. Версия 1.0 появилась в 2006 году, в 2014 представлен релиз 4.0. Основной код доступен под BSD-подобной лицензии, но есть и коммерческие модули.
Появившись проект сразу привлек себе внимание весьма громкими заявлениями своего автора и одного из разработчиков FreeBSD Пол-Хеннинга Кампа (Poul-Henning Kamp), о том что все, что есть (с намеком на Squid) сделано не правильно. И действительно Varnish выделяет современный дизайн эффективно использующий возможности современных многопроцессорных систем (Sqiud научился работать с SMP чуть позже с версии 3.2). Многопоточность реализована с помощью стандартных потоков POSIX, их количество регулируется. Это одна из причин почему Varnish не очень хорошо работает в Windows. Каждый запрос обрабатывается в отдельном потоке. Причем с версии 4.0 за получение запроса от пользователя и передача запроса серверу отвечают разные потоки, что еще более повысило производительность. Varnish поддерживает технологию ESI (Edge Side Includes) позволяющую разбивать веб-страницу на части и запрашивать их отдельно. Кэш может хранить любую информацию. В итоге Varnish отлично подходит для кэширования динмамического контента.
Для хранения данных (кэша, журналов операций) используется виртуальная память, управлением того что выгружается на диск занимается ОС. Здесь авторы Varnish справедливо считают, что разработчики ОС свое дело знают, а дублирование только ухудшает производительность.
В отличие от Squid который изначально больше ориентировался на кэширование клиентских запросов, Varnish был разработан и оптимизирован именно в качестве ускорителя HTTP и ничего другого больше не умеет. Мы не найдем здесь поддержку остальных протоколов (FTP, SMTP и прочие), не увидим возможности прямого прокси — кэширования веб-страниц для экономии внешнего трафика (Varnish «привязывается» к бэкэндам). Естественно отличается и возможности по конфигурированию.
Язык конфигурации Varnish Configuration Language (VCL) — динамический, скрипт сам по себе по сути является отдельным плагином. Код транслируется в С (можно сразу писать встраиваемый код на С), после чего инструкции компилируются в библиотеку и подгружаются в память. Можно вносить изменения в конфигурацию «на лету». Инструкции в VCL позволяют: кэшировать только определенные запросы, снижая нагрузку при генерации динамических объектов, блокировать доступ к определенным каталогам и скриптам, подменять заголовки и многое другое. Есть и механизм проверки работоспособности бэкендов (замер времени ответа, счетчик неудачных проверок и т.д.), возможность перезаписи и перенаправления (rewrite) запросов. Вообще такой подход позволяет производить с HTTP трафиком практически любые манипуляции, которые можно ограничить только собственным воображением. Поддерживается балансировка нагрузки несколько алгоритмов (round robin, random и DNS, Client IP). Возможности расширяются при помощи модулей, называемых VMOD (Varnish MODules). Проект предоставляет необходимую документацию позволяющих написать такой модуль самостоятельно. Часть модулей (varnish-cache.org/vmods) уже включены в стандартную поставку, некоторые доступны в виде концепта или находятся в разработке.
Проект уже предоставляет большое количество модулей

Сегодня Varnish используют такие веб-сервисы как Facebook, Twitter, Vimeo и Tumblr.

Установка и базовая настройка Varnish

Официально рекомендуется установка Varnish на современных версиях x64 битных Linux, FreeBSD или Solaris. Пакеты можно найти в дополнительных репозитариях (вроде EPEL или Ubuntu Universe) большинства дистрибутивов Linux и портах *BSD систем. Сам проект предоставляет репозитарии и подробные инструкции для Red Hat, Debian, Ubuntu и FreeBSD. В большинстве случаев следует использовать именно репозитарий разработчика, так как в нем находится более свежая версия продукта. Возможна работа и в Windows (через Cygwin), но оптимизация под *nix системы не гарантируют максимальную производительность результата. На сайте доступны две версии Varnish 3.x и 4.x, обе являются стабильными, но поддержка линейки 3.x будет прекращена в первой половине 2015 года. Кстати код достаточно хорошо написан, поэтому исправлений вносится мало (например 3 ветка появившаяся в июне 2011 содержала всего 6 версий) можно не боятся использовать свежие релизы. Стандартно Varnish ставится перед веб-сервером кэшируя запросы. В нагруженных системах иногда используют более сложный вариант, когда вначале запрос принимает легкий веб-сервер (nginx, lighttpd), который умеет быстро отдавать определенные страницы. При необходимости этот сервер, через Varnish обращается к основному HTTP-серверу генерирующему контент. Varnish при наличии информации в кэше отдает ее оттуда.
Для примера установим Varnish в Ubuntu 14.04 LTS в качестве фронтэнда Apache. В других дистрибутивах отличия только в расположении конфигурационных файлов и особенностях пакетных систем.

Вот собственно и все. После установки Varnish стартует и что-то там кэширует. Займемся конфигурированием.
Установки параметров запуска демона производится в файле /etc/default/varnish. Первоначально он сконфигурирован с некоторыми параметрами. Если открыть файл, то увидим внутри три готовые настройки: minimal, c VCL и advanced.
Файл /etc/default/varnish

По умолчанию активирован второй режим. При этом сервер принимает подключения на порт 6081, для администрирования используется localhost:6082, а бэкэнд определяются в VCL. Для кэширования выделяется 256 Мб памяти. Настроим так чтобы Varnish слушал 80 порт, кэшируя запросы HTTP сервера расположенного на этой же машине. Комментируем настройки 2 варианта и в качестве шаблона будем использовать Advanced, как более наглядный.

Это основные установки. С остальными можно познакомиться в файле или в документации проекта.
Перестраиваем Apache, чтобы он слушал 8080 порт. В зависимости от текущих установок это можно сделать в разных файлах, в общем идея выглядит так:

Минимальные установки готовы. Перезапускаем Varnish:

Проверяем при помощи netstat слушается ли порт и доступен ли веб-сервер.

Продвинутые настройки

Это самый простой пример и как видим заставить Varnish кэшировать запросы очень легко, но он пока не «разбирается» и не вмешивается в трафик. Познакомившись с VCL можно расширить базовые возможности. Параметров которые можно настроить очень много и чтобы их описать потребуется книга. VCL это язык программирования в котором найдем все что присуще — переменные, функции, комментарии и т.п. Вариантов использования много и сходу их освоить не получится. В качестве отправной точки можно рекомендовать документацию проекта, в частности Varnish Book(varnish-software.com/static/book). Также в Сети уже есть достаточно шаблонов(github.com/mattiasgeniar/varnish-3.0-configuration-templates) под разные ситуации подготовленных самими пользователями. Они являются хорошим подспорьем по изучению возможностей VCL.
Varnish способен работать с несколькими HTTP-серверами (бэкендами). Каждый определяется аналогично примеру выше:

После чего можно строить правила указывая сервера по имени.
Если бэкенды равнозначны и используются только для распределения нагрузки, то достаточно сообщить об этом Varnish с помощью директивы “director”:

Можно также использовать случайный выбор – для этого вместо “round-robin” необходимо прописываем “random”.
Возможна реализация и более сложных алгоритмов. Но для этого нужно познакомиться с возможностями VCL файлов.
В default.vcl мы увидим несколько именованных блоков (функций). По умолчанию параметры внутри отсутствуют, вот именно с их помощью и производится тонкая настройка кэширования. Кое-что можно установить не вникая в работу приложений на веб-сервере, в более сложных случаях потребуется глубокий анализ выдаваемых страниц (проект предоставляет некоторые утилиты о которых дальше).
Разберем некоторые из них. Порядок вызова функций наглядно показан в разделе [VCL Basics](varnish-software.com/static/book/VCL_Basics.html), некоторые вопросы конфигурирования есть в [документации](varnish-cache.org/docs).
Списки ACL позволяют упралявть доступом к определенным URL или вручную распределять или обрабатывать запросы некоторых клиентов. Создадим правило которое включает все локальные узлы.

Как видим разрешается инвертирование при помощи «!» т.е. 192.168.1.10 не попадает под правило. Теперь к этому списку можем обратиться при помощи конструкции (client.ip

local)
Функция vcl_recv вызывается при получении запроса и перед проверкой данных в кэше. Именно здесь можно модифицировать запрос, удалить Cookie, произвести нормализацию, выбрать бэкэнд в зависимости от запроса и т.д.
По умолчанию Varnish не кэширует запросы с установлены Cookie. Для статических страниц, лучше активировать такую возможность, для этого просто вырезаем Cookie. Также для примера запретим доступ к файлам cron.php и install.php для всех узлов кроме локальных и скажем Varnish, чтобы он перенаправлял все запросы к update.php сразу на бэкэнд.

Это конечно не все что можно сделать. Используя req.http.User-Agent можем распределять бэкенды в зависимости от браузера/устройства клиента. Подробнее (varnish-cache.org/docs/trunk/users-guide/devicedetection.html).
Функция return в случае с vcl_recv может принимать аргументы: lookup — указывает на необходимость поиска в кэше, pass — сразу отправляет запрос на бэкэнд. Последнее как видим позволяет избежать кэширования определенных типов файлов, например медиа или постоянно обновляющегося контента.
Некоторые функции вызывают пустыми, просто чтобы пропустить определенную проверку указав нужный код возрата. Кроме указанных выше возможны варианты — deliver, fetch, hash, pipe, error, restart, retry.
Функция vcl_hash позволяет определить уникальность запроса, который будет кэшироваться. По умолчанию хэш формируется на основании URL и IP/имени сервера. В большинстве случаев этого достаточно, но в некоторых ситуациях этого нехватает и возможно потребуется изменение правил. Например, для определения уникальности используют Сookie.
Функция vcl_error позволяет генерировать контент не обращаясь к веб-серверу, используется для выдачи сообщений об ошибках и редиректа.
Далее в зависимости от ситуации запрос обрабатывается vcl_fetch, vcl_pass и vcl_miss. В 4.0 они заменены более удобные функции vcl_backend_fetch и vcl_backend_response, которые вызываются перед передачей запроса серверу и после получения ответа, соотвественно.
В следующем примере мы убираем выставление cookie для файлов изображений, а также задаем время жизни кэшированного содержимого для этих файлов в 1 час.

И перед отправкой полученных от бэкэнда данных вызывается функция vcl_deliver. В простейшем случае она пустует, то есть ответ передается без изменений. Но здесь можно при желании модифицировать заголовки. Для примера просто удалим все упоминания о Varnish:

Это конечно далеко не все возможности, но нужно идти дальше.

Управление Varnish

Работой Varnish можно управлять и отслеживать результат. Для этого в поставке идет несколько утилит начинающихся с varnish*. Все они описаны в разделе «Appendix A: Varnish Programs» Varnish Book. Основной утилитой является varnishadm. Именно с ее помощью производится администрирование, просмотр статуса и ошибок, загрузка модулей «на лету». Принцип работы очень прост. Вызываем:

После чего появится приглашение Varnish CLI. Чтобы получить список команд следует ввести «help».
Список команд varnishadm

Команд не много (23), значение большинства понятно из названия. Подробности по каждой можно получить введя «help команда«. Например, группа команд vcl.* позволяют просматривать и управлять загрузкой, выгрузкой модулей. Смотрим список модулей:

Команды param.show и param.set позволяют просматривать и изменять параметры сервиса, panic.show и panic.clear — отображать и очищать ошибки, ban и ban.list — указывать страницы не подлежащие кэшированию. И так далее.
Две команды varnishtop и varnishhist очень помогают при первоначальной настройки т.к. позволяют просмотреть список наиболее частно встречающихся параметров (URL, идентификаторы, статус и т.д.). Первая утилита выводит их в виде top, вторая как гиксограму. При запросе можно использовать регулярные выражения, поэтому потеряться в большом количестве страниц невозможно. Например, просмотрим список наиболее запрашиваемых URL и заголовки:

Еще три очень полезных утилиты позволяющие просмотреть статистику (varnishstat), и информацию в журналах (varnishlog и varnishncsa). Скрипт varnishtest дает возможность проверить работу кэша Varnish.
Для тех кто не хочет разбираться с командной строкой разработчик предлагают веб-интерфейс Varnish Administration Console (varnish-software.com/resources/vac-demo) — очень удобный инструмент предлагающий произвести все описанные операции и получать статистику в наглядном виде.
Интерфейс Varnish Administration Console

Правда есть минус — доступен он только в коммерческой версии Varnish Plus.
Бесплатное ПО пока не богато вариантами. Плагины поддерживающие Varnish есть в системах мониторинга Collectd, Nagios, Cacti и других. Список известных проектов можно найти на сайте (varnish-cache.org/utilities).

!

(6.jpg)

Вывод

Varnish это очень гибкая программа позволяющая управлять кэшированием трафика с веб-ресурсов. Большие возможности подразумевают большое количество настроек. Поэтому некоторое время придется затратить на их изучение и подгонку под конкретные условия. Но результат того стоит.

Источник

Varnish Cache. Как это работает и как использовать его на вашем сайте WordPress

Главное меню » Блог-платформа wordpress » Varnish Cache. Как это работает и как использовать его на вашем сайте WordPress

На первый взгляд, кеширование может показаться очень сложной темой: мы не будем лгать, в большинстве случаев это так! Но хорошая новость в том, что мы здесь, чтобы помочь.

Все системы кеширования работают по одному принципу:

Кэширование – это процесс хранения данных во временном хранилище, которое называется кеш.

Все идет нормально. Сложность проявляется, когда мы пытаемся определить единицу хранения, над которой работает наш процесс кэширования. Кэширование может принимать различные формы и использовать различные аспекты нашего веб-сайта.

Вот краткий список различных типов кэширования, которые мы можем определить:

В этой статье мы сосредоточимся на последнем типе кэширования и, в частности, на одном из самых популярных обратных прокси-серверов HTTP: Varnish cache.

Понимание обратных прокси HTTP

Вообще говоря, «Прокси» – это сервер, размещенный между Интернетом и пользователем (или сетью пользователей, такой как ЛВС). Прокси-сервер предназначен для фильтрации запросов, отправленных пользователем на определенную веб-страницу, следуя определенному правилу.

Классическим примером прокси-сервера (также называемого прямым прокси-сервером ) является тот, который реализован несколькими компаниями, желающими заблокировать доступ сотрудников к некоторому контенту в Интернете (например, веб-сайты социальных сетей).

С другой стороны, обратный прокси-сервер – это сервер, размещенный между Интернетом и веб-сервером компании. Обратный прокси-сервер – это точка входа всех запросов, направленных на веб-сайт компании: его задача – отфильтровать эти запросы до того, как они достигнут сайта.

Наиболее используемые обратные прокси на рынке:

Некоторые из них, такие как Apache httpd, NGINX, Lighttpd и IIS, также являются веб-серверами, но могут выступать в качестве обратных прокси.

Почему вы должны использовать обратный прокси на вашем сайте?

Ответ прост: есть несколько преимуществ использования обратного прокси. Давайте посмотрим их кратко:

Мы собираемся развить этот последний пункт в следующей главе.

Что такое кеш Varnish?

Теперь, когда вы знаете, что такое обратный прокси-сервер, вы готовы погрузиться в магию Varnish Cache!

Varnish действует как обратный прокси-сервер HTTP-кеша, и иногда вы также можете видеть его как интерфейсный ускоритель. Это не автономное решение, потому что для него нужен выделенный веб-сервер, такой как NGINX или Apache.

Вы можете использовать Varnish для кеширования как динамического, так и статического контента: это эффективное решение для увеличения не только скорости вашего сайта, но и производительности вашего сервера. По словам его разработчиков :

«Это может ускорить доставку в 300–1000 раз, в зависимости от вашей архитектуры».

Каковы преимущества использования Varnish Cache?

Как уже упоминалось, первое преимущество Varnish – это повышение скорости действующего сайта и сервера.

Это происходит благодаря ряду факторов:

Как работает Varnish Cache?

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

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

Кэшированные запросы затем сохраняются в памяти: с этого момента получение и доставка их клиентам будет намного быстрее.

Чтобы указать конфигурацию, политики кэширования и другие правила, Varnish использует язык VCL ( язык конфигурации Varnish ).

Благодаря этому языку и его изменениям вы можете обрабатывать каждый запрос по-разному. Например, вы можете перенаправить определенные запросы в конкретный бэкэнд или попросить Varnish действовать по-разному в зависимости от свойств входящего запроса или его вывода.

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

Опрос бэкэнда опрашивает сервер с частотой, которую вы можете гибко настроить: если Varnish обнаружит время простоя, он продолжит обслуживать кэшированный контент в течение периода, называемого льготным временем (которое также можно настраивать).

Дополнительная информация о командах конфигурации доступна в документации Varnish.

Как использовать Varnish Cache на вашем сайте WordPress?

Миллионы сайтов WordPress используют Varnish Cache.

После того, как Varnish установлен и настроен на вашем веб-сервере, вы готовы дать указание WordPress взаимодействовать с ним и очищать Varnish Cache каждый раз, когда изменяется содержимое в кэше.

Для этого вы можете использовать плагин WordPress: одним из наиболее установленных (и лучше поддерживаемых) является Proxy Cache Purge.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник