Кешування на плечах титанів

З HTTP-кешуванням ви також можете кешувати сторінки цілком (тобто, відповідь), а потім, в обхід додатку, віддавати кешовані дані для кожного запиту. Звичайно ж, це не завжди можна застосувати для дуже динамічних сайтів. Чи все ж можливо? За допомогою Включень крайніх сторін (ESI) ви можете використати силу HTTP-кешування лише для фрагментів вашого сайту.

Система кешування Symfony відрізняється від інших, так як вона покладається на простоту та потужність HTTP-кешування, як це визначено у специфікації RFC 7234 - Кешування. Замість того, щоб винаходити кешування наново, Symfony користується стандартом, який визначає базові комунікації в мережі. Як тільки ви зрозумієте основні моделі HTTP валідації та закінчення строку кешу, ви будете готові до керування системою кешування Symfony.

Так як HTTP-кешування використовується не лише Symfony, існує безліч статей на дану тему. Якщо ви новачок в HTTP-кешуванні, наполегливо рекомендуємо вам прочитати статтю Райана Томайко Речі, які роблять кеші . Іншим вичерпним джерелом є Туторіал з кешу від Марка Ноттінгема.

Кешування за допомогою кешуючого шлюзу

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

Робота кешу полягає у прийманні запитів від клієнта та їх передачі вашому додатку. Кеш також отримуватиме відповідь від вашого додатку та перенаправлятиме його клієнту. Кеш є "посередником" у клієнт-серверних комунікаціях між клієнтом та вашим додатком.

На шляху, кеш зберігатиме кожну відповідь, яку вважає "кешованою" (див. Вступ в HTTP-кешування ). Якщо цей же ресурс буде запитаний ще раз, кеш відправить збережену (кешовану) відповідь клієнту, повністю ігноруючи ваш додаток.

Цей тип кешування відомий під назвою "кешуючий шлюз HTTP шлюза". Існує багато кешерів такого типу, наприклад: 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 = $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-кешу, як тільки будь-який зміст вашого сайту оновлюється.

Щоб дізнатися більше, див. Інвалідація кешу.

Використання Включень крайніх сторін (ESI)

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

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.

Дізнайтеся більше