Varnish + Wordpress + Nginx - Предотвращение необходимости повторной проверки заголовков, не требующих хранения в кэш-памяти.

Question

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

Они сказали, что, поскольку мы использовали Varnish, мы могли довольно легко справиться с потоком трафика.Однако мы не проверяли, что кэширование работает должным образом.Это не было.

---

TLDR: Наше веб-приложение отправляет Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 заголовки с запросами, и нет никаких признаков того, почему это так.

Где можно посмотреть, чтобы предотвратить отправку этих заголовков?

PHP: 5.6 Nginx: 1.4.6 Лак: 1.1 Wordpress: 4.6.12 Лесоматериалы: 1.2.4

LinuxАдминистраторы, с которыми мы работаем, сказали, что они просмотрели конфиги и не нашли ничего, определяющего эти заголовки, кроме запросов AJAX.

#dont cache ajax requests

if(req.http.X-Requested-With == "XMLHttpRequest" || req.url ~ "nocache" || req.url ~ "(control.php|wp-comments-post.php|wp-login.php|bb-login.php|bb-reset-password.php|register.php)")

Вот скручивание из Pre-launch, когда мы правильно настроили Varnish для кеширования послепринудительное использование HTTPS (плагин force-https) на сайте:

$ curl -Ik -H'X-Forwarded-Proto: *************
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Server: *****
Date: Sat, 03 Nov 2018 22:36:43 GMT
X-Varnish: 53061104
Age: 0
Via: 1.1 varnish
Connection: keep-alive

и с момента запуска:

curl -ILk ***********
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
X-Varnish: 691817320
Vary: Accept-Encoding
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=UTF-8
X-Server: ****
Date: Mon, 19 Nov 2018 19:17:02 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Accept-Ranges: bytes
Via: 1.1 varnish
Connection: Keep-Alive
Set-Cookie: X-Mapping-fjhppofk=33C486CB71216B67C5C5AB8F5E63769E; path=/
Age: 0

плагин Force-https: мы активировали его, обновили конфигурацию Varnish, чтобы избежатьцикл перенаправления и подтвердил, что он работал за неделю до запуска.

Плагины: они не изменились, за исключением принудительного https.

Веб-приложение: это обновленная версия предыдущего приложения, полный редизайн, но ничего в приложении от whaЯ могу сказать, что указывает no-store no-cache заголовки для отправки.

С чего мне начать?Спасибо!

Answer 1

Вам нужно исправить бэкэнд, но, по крайней мере, вы можете удалить раздражающий заголовок и / или обойти его лаком с помощью этого фрагмента vcl;

sub vcl_backend_response {
    # kill the CC header so that application downstream don't see it
    unset req.http.Cache-Control;

    # alternatively, you can also override that header with
    # set req.http.Cache-Control = "whatever string you desire";

    # you can also force the TTL
    beresp.ttl;

    # also, if you return now, the builtin.vcl (https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishd/builtin.vcl)
    # doesn't get executed; this is generally the one deciding content is uncacheable
    return (deliver);
}

Answer 2

То, что отправляет эти заголовки, это движок PHP.

Это происходит всякий раз, когда вы инициируете сеанс, что явно происходит на основании присутствия Set-Cookie.

Убедитесь, что сеансы PHP инициируются только тогда, когда это абсолютно необходимо.По умолчанию Varnish не будет кэшироваться, когда ответ включает либо Set-Cookie, либо «отрицательный» Cache-Control, у вас есть оба.

Так что избавление от посторонних вызовов session_start() и / или setcookie() является ключевымздесь.

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