Преглед на конфигурацията на лака - Технически бележки

Полезни бележки.

Преглед на конфигурацията на лака

Има много статии за това как да персонализирате Varnish. Бързам да ви информирам, че няма единен подход за настройка. Колкото повече опции посочите в конфигурационния файл, толкова повече непредвидени обстоятелства могат да се появят.

В тази статия искам да прегледам VCL езика, който се използва при настройване на Varnish и да разгледам опциите за персонализиране. Бързам да обърна внимание на факта, че Varnish не поддържа SSL.

И така, конфигурацията на Varnish е описана в два файла:

  • /etc/default/varnish за Debian/Ubuntu (/etc/sysconfig/varnish за RedHat/CentOS)
  • /etc/varnish/default.vcl

Първият съдържа описание на конфигурацията на демона Varnish. Можете да зададете следните опции:

Ключовият раздел в него е разделът DAEMON_OPTS:

По-долу е даден пример за секцията DAEMON_OPTS. В този случай Varnish ще работи с файла /etc/varnish/default.vcl. Кешът на обектите ще се съхранява във файл от 1 Gb, намиращ се на /var/lib/varnish/$(uname -n)/varnish_storage.bin:

По-долу е даден пример за секцията DAEMON_OPTS. В този случай Varnish ще работи с файла /etc/varnish/website.vcl. Кешът на обектите ще се съхранява в RAM (malloc) и за него ще бъдат отделени 256Mb.

Връщайки се към твърдението, че няма единен подход за настройка, искам да отбележа, че в зависимост от това дали кеширате статики (изображения, css файлове и js скриптове), трябва да посочите различно място за съхранение на кеша.

В моята практика имаше сайтове, чиито страници имаха много статични обекти под формата на снимки, което значително увеличи времето за зареждане на страницата. Снимките рядко се променят. В този случай можете да съхраните кеша във файл налокален диск и кеш цели страници, включително статични обекти. Скоростта на зареждане на страници се увеличи значително с този подход (3-5 пъти).

Този блог се върти на слаб сървър, страниците са леки и не изискват много ресурси за доставка. Varnish е конфигуриран по такъв начин, че да изпраща статични заявки директно към Nginx и да кешира/издава останалите от кеша. В този случай обектите се съхраняват в RAM с лимит от 256 MB. Това е напълно достатъчно.

Да разгледаме файл с разширение vcl в папката /etc/varnish и е указан от ключа "-f" в секцията DAEMON_OPTS. Започва с описание на така наречените бек-ендове. В този случай бекендът е същият Apache или NginX, на който се върти сайтът. Този раздел изглежда така:

Можете да добавите проверка на жизнеността:

Ако имате няколко сървъра и също така използвате Varnish като балансьор на натоварването, тогава можете да декларирате няколко бекенда и да ги комбинирате в директор:

Това, което следва, е описание на така наречените „подпрограми“ или „Подпрограми“, които се прилагат за всички заявки, предадени през Varnish.

  • vcl_recv
  • vcl_pipe
  • vcl_pass
  • vcl_hash
  • vcl_hit
  • vcl_miss
  • vcl_fetch
  • vcl_deliver
  • vcl_грешка

Цялостният работен поток на Varnish може да бъде описан с помощта на следната диаграма:

конфигурацията

1. vcl_recv отговаря за първоначалната обработка на заявката. По-нататъшната съдба на обработката на заявката се определя тук с помощта на функцията return (). Можете да решите съдбата на заявката с:

  • pass - изпращане на заявка до vcl_pass.
  • pipe изпрати заявка до vcl_pipe.
  • lookup - потърсете искания обект в кеша

За да деактивиратеза да използвате кеша за всички заявки, различни от типа GET, добавете следните редове към този раздел:

Следната конструкция ще деактивира използването на кеша за административната област на блога на WordPress. Съответно wp-admin може да бъде променен на стойността, от която се нуждаете:

За да деактивирате използването на кеш за статични файлове и да премахнете информацията за бисквитките от заявките, добавете следните редове към този раздел:

По същия начин можете да изпращате всички заявки за статични файлове към отделен бек-енд, ако го имате за тези цели:

Възможно е да се използва конкретен бекенд в зависимост от HOST стойността в заглавките на заявката. Да приемем, че имате dev версия на сайта и тя се намира на един от описаните бек-ендове (да речем www2):

Нормализирането на кодирането може да бъде полезно:

Секцията се затваря от функцията за връщане () с аргумент за пропуск, канал или търсене.

2. Когато заявка достигнеvcl_pass, тя се доставя до директния бек-енд, заобикаляйки кеша.

3. Когато заявка попадне наvcl_pipe, възниква един вид клиентско затваряне към задния край. Лакът пуши отстрани или обработва други заявки. Честно казано, не виждам голяма разлика между vcl_pass и vcl_pipe.

4. vcl_hash е отговорен за създаването на моментна хеш снимка на обекта в хранилището на кеша. Няма допълнителни опции.

5. vcl_miss се задейства, ако исканият обект не е намерен в хранилището на кеша. Изпраща обекта към vcl_fetch по подразбиране.

6. vcl_hit се задейства, ако исканият обект е намерен в хранилището на кеша. По подразбиране изпраща обекта за обработка от vcl_deliver.

7. vcl_fetch се задейства, когато исканият обект е извлечен от задния край.

За да зададете живота на обект в кеш паметта, трябва дапърво премахнете заглавката, указваща живота на обекта:

И след това посочете живота на обекта в хранилището (в секунди):

8. vcl_deliver се задейства преди обектът да бъде доставен от кеша на клиента. Тук можете да добавите или премахнете необходимите заглавки (заглавки) в http отговора: