Кеширование на плечах титанов

C HTTP-кешированием, вы можете кешировать страницы целиком (т.е. ответ), и затем, в обход приложения, отдавать кэшированные данные для каждого запроса. Конечно же, это не всегда возможно применить для очень динамичных сайтов, или всё же возможно? С помощью Включений крайней стороны (ESI) вы можете использовать силу HTTP-кеширования только для фрагментов вашего сайта.

Система кеширования Symfony отличается от других, так как она полагается на простоту и мощь HTTP-кеширования, как это определено в спецификации RFC 7234 - Кеширование. Вместо того, чтобы изобретать кеширование заново, Symfony пользуется стандартом, который определяет базовые коммуникации в Web. Как только вы поймёте основополагающие модели HTTP валидации и истечения срока кэша, вы будете готовы к управлению системой кеширования Symfony.

Так как HTTP-кеширование используется не только Symfony, существует множество статей по данной теме. Если вы новичок в HTTP-кешировании, настоятельно рекомендуем вам прочитать статью Райана Томайко Вещи, которые делают кеши . Другим исчерпывающим источником является Учебное пособие по кешу от Марка Ноттингема.

Кеширование при помощи кеширующего шлюза

При HTTP-кешировании, кеш полностью отделён от вашего приложения и располагается между вашим приложением и клиентом, выполняющим запрос.

Работа кеша заключается в приёме запросов от клиента, и их передаче вашему приложению. Кеш также будет получать ответ от вашего приложения и перенаправлять его клиенту. Кеш является «посредником» в клиент-серверных коммуникациях между клиентом и вашим приложением.

По пути, кеш будет сохранять каждый ответ, который полагает "кешируемым" (см. ). Если этот же ресурс будет запрошен ещё раз, кеш отправит сохранённый (кешированный) ответ клиенту, полностью игнорируя ваше приложение.

Этот тип кeширования известен под именем "кeширующего HTTP шлюза". Существует много кeшеров такого типа, например: Varnish, Squid в режиме обратного прокси, а также обратный прокси Symfony.

1
2
3
4

# config/packages/framework.yaml
when@prod:
    framework:
        http_cache: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/framework.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:framework="http://symfony.com/schema/dic/symfony"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/symfony
        https://symfony.com/schema/dic/symfony/symfony-1.0.xsd">

    <when env="prod">
      <framework:config>
          <!-- ... -->
          <framework:http-cache enabled="true"/>
      </framework:config>
    </when>
</container>

1
2
3
4
5
6
7
8

// config/packages/framework.php
use Symfony\Config\FrameworkConfig;

return static function (FrameworkConfig $framework) use ($env) {
    if ('prod' === $env) {
        $framework->httpCache()->enabled(true);
    }
};

Делаем ваши ответы HTTP-кешируемыми

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

HTTP определяет четыре заголовка ответакеша, которые вы можете активировать:

• Cache-Control
• Expires
• ETag
• Last-Modified

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

1. Кеширование окончания срока действия Используется, чтобы кешировать весь ваш ответ на определенное количество времени (например, 24 часа). Просто, однако девалидация кеша более сложная.
2. Кешировани валидации Более сложная модель: используется, чтобы кешировать ваш ответ, но позволяет вам динамически инвалидировать его, как только ваш контент изменяется.

1
2
3
4
5
6
7
8
9

// src/Controller/BlogController.php
use Symfony\Component\HttpKernel\Attribute\Cache;
// ...

#[Cache(public: true, maxage: 3600, mustRevalidate: true)]
public function index(): Response
{
    return $this->render('blog/index.html.twig', []);
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// src/Controller/BlogController.php
use Symfony\Component\HttpFoundation\Response;
// ...

public function index()
{
    // создайте объект Response любым способом, например, отобразите шаблон
    $response = $this->render('blog/index.html.twig', []);

    // кешировать на 3600 секунд
    $response->setPublic();
    $response->setMaxAge(3600);

    // (необязательно) установите пользовательскую директиву
    $response->headers->addCacheControlDirective('must-revalidate', true);

return $response;

1

Cache-Control: public, s-maxage=3600, must-revalidate

1
2
3
4
5

// помечает ответ как "просроченный"
$response->expire();

// форсирует возврат ответа 304 без контента
$response->setNotModified();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// используйте этот метод, чтобы установить несколько настроек кеша за один вызов
// (этот пример перечисляет все доступные настройки кеша)
$response->setCache([
    'must_revalidate'  => false,
    'no_cache'         => false,
    'no_store'         => false,
    'no_transform'     => false,
    'public'           => true,
    'private'          => false,
    'proxy_revalidate' => false,
    'max_age'          => 600,
    's_maxage'         => 600,
    'immutable'        => true,
    'last_modified'    => new \DateTime(),
    'etag'             => 'abcdef'
]);

Инвалидция кеша

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

Чтобы узнать больше, см. Аннуляция кеша.

Использование Включений крайней стороны

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

HTTP-кеширование и сессии пользователей

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

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

Для того, чтобы отключить поведение Symfony по умолчанию, которое делает запросы, использующие сессии, некешируремыми, додайте следующий внутренний заголовок к вашему ответу и Symfony его не изменит:

1
2
3

use Symfony\Component\HttpKernel\EventListener\AbstractSessionListener;

$response->headers->set(AbstractSessionListener::NO_AUTO_CACHE_CONTROL_HEADER, 'true');

Заключение

Symfony создан таким образом, чтобы следовать проверенным «правилам движения» в HTTP. Кеширование - не исключение. Овладение системой кеширования Symfony, подразумевает близкое знакомство с моделями кэширования HTTP и их эффективное использование. Это означает, что вместо того, чтобы полагаться только на документацию Symfony и примеры кода, вы получаете доступ к целому миру знаний, относящихся к кешированию в HTTP и кеширующим шлюзам, таким как Varnish.

Узнайте больше