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

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, string $env): void {
    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

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

public function index(): Response
{
    // создайте объект 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.

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