Как ускорить работу вашего сайта Drupal 7 с помощью Varnish 4 в Ubuntu 14.04 и Debian 7

Вступление

Фон

Drupal * - одна из самых популярных бесплатных систем управления контентом с открытым исходным кодом.

Поскольку он использует базовую базу данных для хранения и извлечения данных, таких как контентные страницы, новости, комментарии и сообщения в блогах, Drupal требуется значительное количество вычислительной мощности для обслуживания одного просмотра страницы. Каждый показ страницы включает в себя запуск интерпретатора PHP, обработку всех элементов Drupal, доступ к базе данных для получения информации, подготовку визуального макета и передачу готового контента пользователю.

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

Есть много способов приспособиться к росту и справиться с проблемами производительности, большинство из которых можно считать методом scaling. Масштабирование с точки зрения программного обеспечения считается способностью системы выдерживать повышенную нагрузку, например, увеличение количества одновременных посетителей.

Лак * помогает с масштабированием на программном уровне, добавляя дополнительное программное обеспечение, которое может помочь в устранении узких мест.

Эта статья была протестирована на * Ubuntu 14.04 *, но должна работать с небольшими изменениями пути на * Debian 7 *. Он может работать и в других дистрибутивах с небольшими изменениями.

Лак кеш

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

Его можно использовать для обслуживания статического содержимого, такого как изображения, сценарии или таблицы стилей, поскольку Varnish невероятно быстр и справляется с трафиком намного лучше, чем * Apache *. Его также можно использовать для кэширования quasi-static содержимого; то есть контент, который генерируется приложением динамически (с использованием базы данных и на подготовку которого уходит значительное количество времени), но который остается неизменным в течение определенного периода времени, что делает контент пригодным для кэширования.

Например, когда статья на сайте публикуется, она редко обновляется. Тогда совершенно не нужно задействовать все фрагменты обработки Drupal, чтобы вычислять и показывать одну и ту же статью каждый раз, когда она запрашивается. Для Varnish будет прекрасно вспомнить, чтобы он снова служил на той же странице, не связываясь с Drupal вообще. Это позволяет Varnish легко обслуживать один и тот же контент одновременно для 10, 100 или даже 1000 человек, поскольку для обслуживания кэшированной страницы требуется очень мало вычислительной мощности.

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

Предпосылки

В статье предполагается, что у вас есть работающий * Drupal * веб-сайт на LAMP, который уже запущен и работает. Вот требования:

A * Ubuntu 14.04 * или * Debian 7 * Droplet (протестировано в Ubuntu 14.04)
Пользователь sudo
LAMP
Drupal

Шаг 1 - реконфигурирование Apache

По умолчанию * Apache * прослушивает порт 80. Это позволяет Apache обрабатывать веб-запросы, такие как запрос URL-адреса браузера для * http: //example.com*. Чтобы использовать * Varnish *, он должен иметь возможность обрабатывать эти запросы. Сначала мы должны сказать Apache больше не обрабатывать запросы на порту 80.

Изменение порта Apache прослушивает

Порт, который прослушивает * Apache * по умолчанию, задается в файле с именем, который на обоих языках * Debian * и * Ubuntu * находится в + / etc / apache2 +.

Отредактируйте файл:

sudo nano /etc/apache2/ports.conf

Это запустит текстовый редактор * nano *, показывающий содержимое этого файла по умолчанию, которое должно быть похоже на следующее. Обновите + NameVirtualHost + и строки для использования порта * 81 *:

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:
Listen

<IfModule mod_ssl.c>
   # If you add NameVirtualHost *:443 here, you will also have to change
   # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
   # to <VirtualHost *:443>
   # Server Name Indication for SSL named virtual hosts is currently not
   # supported by MSIE on Windows XP.
   Listen 443
</IfModule>

Давайте сохраним файл, нажав * CTRL + x *, затем * y *, затем * Enter *.

Изменение порта для виртуального хоста

По умолчанию в новой установке * Apache * один виртуальный хост указан в файле конфигурации, расположенном в + / etc / apache2 / sites-enabled / 000-default +. Если у вас настроено более одного виртуального хоста, вам придется изменить * все * из них.

Чтобы изменить конфигурацию виртуального хоста Apache по умолчанию, введите:

sudo nano /etc/apache2/sites-enabled/000-default.conf

Содержимое файла начинается со строк вроде следующего:

<VirtualHost *:80>
       ServerAdmin webmaster@localhost

Как и раньше, мы должны изменить число с * 80 * на * 81 *:

<VirtualHost *:>
       ServerAdmin webmaster@localhost

Сохраните файл, используя * CTRL-x *, за которым следуют * y * и * Enter *.

Перезагрузка конфигурации Apache

После этих изменений необходимо обновить конфигурацию Apache:

sudo service apache2 reload

Теперь Apache будет принимать входящие запросы на новый порт * 81 *, а не на * 80 *, как раньше.

Мы можем подтвердить это, открыв наш веб-сайт в браузере - он не должен открываться без указания порта (например, * http: //example.com*), но отображается правильно после добавления нового порта в адрес (например, * http: / /example.com:81*).

Теперь мы готовы установить и настроить * Varnish *, чтобы помочь нам сделать сайт быстрее.

Шаг 2 - Установка лака

И Debian, и Ubuntu имеют системные пакеты с * Varnish *, но мы рекомендуем использовать готовые пакеты, созданные авторами Varnish. Это обеспечит актуальность Varnish, что не относится к системным пакетам.

Сначала убедитесь, что установлен пакет * apt-transport-https *, который позволяет системе устанавливать пакеты через безопасное соединение:

sudo apt-get install apt-transport-https

Это либо установит необходимый пакет, либо сообщит нам, что он уже установлен.

Для проверки подлинности установленных пакетов необходимо установить открытый ключ сервера пакетов Varnish. Сначала переключитесь на * root *:

sudo su

Добавьте ключ:

curl https://repo.varnish-cache.org/ubuntu/GPG-key.txt | apt-key add -

Для * Debian *:

echo "deb https://repo.varnish-cache.org/debian/ wheezy varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list

Для * Ubuntu *:

echo "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list

Теперь вы можете вернуться к своему пользователю sudo. *

Обновите вашу систему:

sudo apt-get update

Установите лак:

sudo apt-get install varnish

Это устанавливает и запускает Varnish!

Шаг 3 - Заставить лака слушать порт 80

По умолчанию Varnish прослушивает порт * 6081 *. Вместо этого мы заставим Varnish прослушивать порт * 80 *, принимая все входящие запросы от наших веб-пользователей, как это делал ранее * Apache *.

Давайте откроем файл конфигурации Varnish, используя:

sudo nano /etc/default/varnish

Найдите раздел без комментариев, показанный ниже:

. . .

## Alternative 2, Configuration with VCL
#
# Listen on port 6081, administration on localhost:6082, and forward to
# one content server selected by the vcl file, based on the request.
# Use a 256MB memory based cache.
#
DAEMON_OPTS="-a :6081 \
            -T localhost:6082 \
            -f /etc/varnish/default.vcl \
            -S /etc/varnish/secret \
            -s malloc,256m"

. . .

Обновите строку, чтобы использовать порт * 80 * (не забудьте также сохранить + \ +):

. . .

DAEMON_OPTS="-a : \
            -T localhost:6082 \
            -f /etc/varnish/default.vcl \
            -S /etc/varnish/secret \
            -s malloc,256m"

. . .

Сохраните файл, используя * CTRL-x * и * y *, а затем * Enter *.

Перезапустите * Varnish *, чтобы изменения вступили в силу:

sudo service varnish restart

Мы должны увидеть такие сообщения без ошибок:

[ ok ] Stopping HTTP accelerator: varnishd.
[ ok ] Starting HTTP accelerator: varnishd.

Теперь проверьте ваш сайт в браузере. Вместо вашего ранее доступного сайта Drupal вы увидите белую страницу с сообщением об ошибке:

Error 503 Backend fetch failed

Backend fetch failed

Guru Meditation:
XID: 131081

Varnish cache server

Это означает, что Varnish правильно настроен для приема входящих соединений, но еще не доступен для обслуживания нашего сайта Drupal. Мы внесем изменения в конфигурацию, чтобы вернуть прежний сайт Drupal в рабочее состояние, выполнив следующие действия.

Как работает лак

Отличным ресурсом для полного понимания * Varnish * является официальная Varnish Book, но мы рассмотрим несколько основных фактов о том, как * Лак * работает здесь.

Вы также можете перейти к следующему шагу, если хотите завершить установку сейчас и узнать больше позже. Однако, если вы узнаете, как работает Varnish, вы лучше поймете следующие шаги.

VCL Language

Конфигурация Varnish написана на языке * VCL * (Язык конфигурации Varnish). Это простой язык программирования, который компилируется в собственный код * C * самой Varnish.

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

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

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

Другие инструкции выполняются, когда Varnish обслуживает кэшированный контент, не извлекая его свежим из приложения.

Используя * VCL *, можно создать сложную логику, принимающую различные решения для кэширования, основываясь на многих факторах. Также возможно создать очень простой набор инструкций.

Varnish поставляется с разумной реализацией по умолчанию для * всех * его методов, которые могут быть изменены при необходимости. Это означает, что в конфигурации можно указать только * некоторые * методы, и даже тогда только * некоторые * инструкции, все еще полагаясь на значения по умолчанию. Это позволяет очень просто использовать базовые способности Varnish, в то же время позволяя создавать очень сложные конфигурации по мере добавления пользовательских инструкций.

Что кэшируется, а что нет?

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

При обычной установке Drupal это может привести к двум различным проблемным сценариям.

Первый - когда кешируется недостаточно страниц, что делает Varnish почти ненужным. Это совсем не ускоряет процесс, поскольку большинство страниц каждый раз выбирается непосредственно из приложения Drupal. Это не помогает с проблемами производительности, но и ничего не ломает.

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

Давайте рассмотрим некоторые общие факторы, которые помогут нам решить, будет ли * Varnish * кэшировать контент.

Лак кеширует все

В сценарии по умолчанию основная предпосылка заключается в том, что Varnish кэширует * все *. Кэширование в Varnish является exclusive, а не inclusive, что означает, что все кэшируется, если вы не сделаете правило иначе.

Метод запроса

Метод запроса является основным определением запроса. Лак по умолчанию кэширует * только * GET и HEAD запросы, * никогда * не кэширует другие, такие как POST, PUT и DELETE. Это гарантирует, что запросы, предназначенные для внесения некоторых изменений в данные, поступят в приложение в целости и сохранности без кэширования.

авторизация

По умолчанию запросы к защищенным паролем страницам вообще не кэшируются. * Это относится только к страницам, защищенным с помощью HTTP Basic Authorization *. Varnish не знает о механизмах, специфичных для приложения, таких как страницы входа в Drupal. Мы должны будем добавить наши собственные правила, чтобы убедиться, что страницы входа не кэшируются.

Заголовки кэша

Иногда веб-приложения возвращают свою собственную информацию о кэшировании в заголовках. Varnish учитывает эти заголовки, поэтому, когда веб-приложение, такое как Drupal, говорит Varnish никогда не кэшировать его ответ, это именно то, что произойдет, если мы не запрограммируем другое поведение в файле * VCL *. Поскольку Drupal отправляет свою собственную информацию о кэшировании, это станет важным в дальнейшем.

Печенье

Cookies, пожалуй, самая важная и самая трудная часть принятия решений о кэшировании с помощью веб-приложений.

По умолчанию, если установлены файлы cookie запроса * или * ответа, страница * не * будет кэшироваться. Это разумное решение, так как, например, вошедшие в систему пользователи идентифицируются сессионным cookie. Если бы страницы с файлами cookie были кэшированы, все вошедшие в систему пользователи получали бы одинаковое содержимое, и приложение не могло бы различить пользователей. Однако это также один из самых больших источников проблем, поскольку использование файлов cookie широко распространено. Часто в запросах присутствуют безвредные файлы cookie, такие как токены * Google Analytics *, которые вообще не используются приложением, но также делают содержимое не кэшируемым. Без тщательных решений о том, какие файлы cookie должны запрещать кэширование, а какие следует игнорировать, в современных веб-приложениях мы бы практически не кэшировали, поскольку вокруг так много файлов cookie.

Большинство фрагментов специфичной для Drupal конфигурации для Varnish будут иметь дело с правильной обработкой файлов cookie, чтобы удалить ненужные файлы cookie и разрешить кэширование, но при этом сохранить те, которые необходимы, например, для поддержки функциональности страницы администрирования.

Шаг 4 - Настройка Varnish для Drupal

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

Давайте откроем файл конфигурации Varnish VCL:

sudo nano /etc/varnish/default.vcl

Содержимое по умолчанию показывает все методы Varnish пустыми, что означает, что используются значения по умолчанию.

Мы можем добавить наши собственные инструкции по настройке для достижения необходимой политики кэширования.

Первый блок инструктирует Varnish, как связаться с внутренним веб-сервером, который в нашем случае является * Apache * с установкой * Drupal *. Мы изменим код для отражения порта * 81 *, который мы использовали для настройки * Apache *.

. . .

# Default backend definition. Set this to point to your content server.
backend default {
   .host = "127.0.0.1";
   .port = "";
}

. . .

Теперь найдите метод пустого заполнителя + vcl_recv +:

. . .

sub vcl_recv {
   # Happens before we check if we have this in cache already.
   #
   # Typically you clean up the request here, removing cookies you don't need,
   # rewriting the request, etc.
}

. . .

Код в этом методе выполняется before * Varnish *, связывается с нашим * Drupal * сайтом. Это место, где мы можем удалить некоторые файлы cookie, поступающие из браузера, принудительно (или нет) кэшировать определенные адреса и принять первое решение о кэшировании. Мы добавим несколько правил, которые выполняют следующее:

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

Для этого заменим блок по умолчанию следующим. Строки, начинающиеся с * # *, являются комментариями и не будут приниматься во внимание Varnish, но приведены здесь, чтобы облегчить понимание файла конфигурации. Весь этот блок является новым и может быть вставлен как есть:

. . .

sub vcl_recv {

   # Return (pass) instructs Varnish not to cache the request
   # when the condition is met.

   ## ADMIN PAGES ##

   # Here we filter out all URLs containing Drupal administrative sections
   if (req.url ~ "^/status\.php$" ||
       req.url ~ "^/update\.php$" ||
       req.url ~ "^/admin$" ||
       req.url ~ "^/admin/.*$" ||
       req.url ~ "^/user$" ||
       req.url ~ "^/user/.*$" ||
       req.url ~ "^/flag/.*$" ||
       req.url ~ "^.*/ajax/.*$" ||
       req.url ~ "^.*/ahah/.*$") {
          return (pass);
   }


   ## BACKUP AND MIGRATE MODULE ##

   # Backup and Migrate is a very popular Drupal module that needs to be excluded
   # It won't work with Varnish
   if (req.url ~ "^/admin/content/backup_migrate/export") {
       return (pipe);
   }

   ## COOKIES ##

   # Remove cookies for stylesheets, scripts, and images used throughout the site.
   # Removing cookies will allow Varnish to cache those files.
   if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
       unset req.http.Cookie;
   }

   # Remove all cookies that are not necessary for Drupal to work properly.
   # Since it would be cumbersome to REMOVE certain cookies, we specify
   # which ones are of interest to us, and remove all others. In this particular
   # case we leave SESS, SSESS and NO_CACHE cookies used by Drupal's administrative
   # interface. Cookies in cookie header are delimited with ";", so when there are
   # many cookies, the header looks like "Cookie1=value1; Cookie2=value2; Cookie3..."
   # and so on. That allows us to work with ";" to split cookies into individual
   # ones.
   #
   # The method for filtering unnecessary cookies has been adopted from:
   # https://fourkitchens.atlassian.net/wiki/display/TECH/Configure+Varnish+3+for+Drupal+7
   if (req.http.Cookie) {
       # 1. We add ; to the beginning of cookie header
       set req.http.Cookie = ";" + req.http.Cookie;
       # 2. We remove spaces following each occurence of ";". After this operation
       # all cookies are delimited with no spaces.
       set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
       # 3. We replace ";" INTO "; " (adding the space we have previously removed) in cookies
       # named SESS..., SSESS... and NO_CACHE. After this operation those cookies will be
       # easy to differentiate from the others, because those will be the only one with space
       # after ";"
       set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; \1=");
       # 4. We remove all cookies with no space after ";", so basically we remove all cookies other
       # than those above.
       set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
       # 5. We strip leading and trailing whitespace and semicolons.
       set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");

       # If there are no cookies after our striping procedure, we remove the header altogether,
       # thus allowing Varnish to cache this page
       if (req.http.Cookie == "") {
           unset req.http.Cookie;
       }
       # if any of our cookies of interest are still there, we disable caching and pass the request
       # straight to Apache and Drupal
       else {
           return (pass);
       }
   }
}

. . .

Следующий метод -. Этот метод отвечает за обработку ответа от Apache и Drupal перед его помещением в кеш или удалением из кеша. Мы можем изменить то, что посылает Drupal, в соответствии с нашей стратегией кэширования.

Метод по умолчанию выглядит следующим образом:

. . .

sub vcl_backend_response {
   # Happens after we have read the response headers from the backend.
   #
   # Here you clean the response headers, removing silly Set-Cookie headers
   # and other mistakes your backend does.
}

. . .

Давайте заменим его на этот совершенно новый блок как есть. Комментарии включены:

. . .

sub vcl_backend_response {
   # Remove cookies for stylesheets, scripts and images used throughout the site.
   # Removing cookies will allow Varnish to cache those files. It is uncommon for
   # static files to contain cookies, but it is possible for files generated
   # dynamically by Drupal. Those cookies are unnecessary, but could prevent files
   # from being cached.
   if (bereq.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico)(\?.*)?$") {
       unset beresp.http.set-cookie;
   }
}

. . .

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

Давайте сохраним файл конфигурации с помощью * CTRL + x *, затем * y *, а затем * Enter *. Менять другие методы не нужно.

Шаг 5 - перезапуск лака

Перезапустите * Varnish *, чтобы изменения вступили в силу:

sudo service varnish restart

Сервер Varnish должен перезагрузиться без ошибок.

Теперь вы сможете снова просматривать свой веб-сайт Drupal в своем браузере.

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

Шаг 6 - Включение кеширования в Drupal

По умолчанию в Drupal отключены механизмы кеширования. Это приводит к тому, что заголовки отправляются в Varnish, что заставляет страницы вообще не кэшироваться. Таким образом, отключенный кеш Drupal автоматически блокирует Varnish, чтобы помочь нам ускорить работу сайта.

Чтобы включить кэширование Drupal, войдите на свой сайт Drupal как администратор.

Выберите меню * Configuration *, а затем * Performance *.

изображение: https: //assets.digitalocean.com/articles/drupal_varnish/1.png [Меню конфигурации Drupal]

В разделе * Performance * найдите и проверьте настройки * Cache для анонимных пользователей * и * Cache blocks *.

Установите для * Минимальное время жизни кеша * и * Срок действия кэшированных страниц * разумное значение, например * 30 минут *. Это значение дает значительный прирост производительности и при этом гарантирует, что кэш не устареет слишком долго. Наилучшая настройка времени жизни кэша зависит от конкретного сайта и от того, как часто он обновляется. После изменения значений нажмите * Сохранить конфигурацию *.

изображение: https: //assets.digitalocean.com/articles/drupal_varnish/2.png [Настройки кэша]

Это завершает необходимую настройку, чтобы Varnish кэшировал наш сайт на Drupal.

Шаг 7 - Проверка конфигурации лака

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

изображение: https: //assets.digitalocean.com/articles/drupal_varnish/3.png [Рабочий лак]

Возможно, вы захотите проверить дважды, если вы получаете сообщение «сортировка» в первый раз.

Дальнейшее чтение

Темы, рассматриваемые в этой статье, являются лишь верхушкой айсберга. * Varnish * - очень мощное программное обеспечение, которое может помочь не только в простом кешировании. Официальная Varnish документация является обширным ресурсом о возможностях Varnish и синтаксисе VCL. Чтобы максимально использовать возможности Varnish и Drupal, также лучше узнать собственные возможности Drupal с точки зрения повышения производительности. Официальная Drupal документация по производительности является хорошей отправной точкой.

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

TOC