У меня возникли проблемы с моим VPS. Что-то случилось с ним, в чем мои хозяева не уверены, и поэтому мне приходится пройти через испытание, чтобы попытаться перенастроить несколько вещей. Одна из таких вещей - Varnish ... Я разместил здесь вопрос: https://webmasters.stackexchange.com/questions/89506/http-header-if-not-modified-help/89507?noredirect=1#comment109928_89507 при этом я использую WP Super cache для создания статических HTML-файлов страниц с помощью Mod_rewrite для уменьшения нагрузки на сервер. Затем я пропускаю эти статические страницы через Varnish, чтобы еще больше снизить нагрузку.
Проблема, с которой я столкнулся, заключается в том, что WP Super cache отправляет max-age = 3, что, очевидно, через 3 секунды записывается как промах в Varnish еще на 3 секунды. Так что использовать Varnish бессмысленно.
Однако, если установить максимальный возраст контента более длинным, это означает, что если я изменю CSS или динамическую страницу в WordPress, контент в браузере устареет, что, очевидно, мне не нужно.
Мне было интересно (поправьте меня, если это не правильный путь), следуя этому руководству: https://www.varnish-cache.org/trac/wiki/VCLExampleLongerCaching Varnish может вырезать заголовки, отправленные с помощью .htaccess в WordPress, затем кешировать Varnish на неделю (если не очищать его через SSH или через плагин очистки HTTP HTTP, я думаю), а кеш браузера остается низким на 15 минут, поэтому, если что-то изменится , он устареет всего на 15 минут, но по прошествии этих 15 минут следующий запрос все равно будет поступать от Varnish, а не от Apache.
Некоторые из веб-сайтов, за которыми я слежу, являются веб-сайтами с фотографиями, поэтому я действительно не хочу кэшировать ГБ изображений в Varnish, поэтому в настоящее время я сказал своему VCL не кэшировать их. Я хочу только кешировать страницы, чтобы потом избавиться от дополнительных плагинов кеширования, используемых WordPress.
Я попытался увидеть, есть ли способ иметь долгое время кеширования Varnish, тогда WordPress отправит заголовок, который он будет хранить в браузере в течение максимального возраста, скажем, 1 день, но если контент обновлен (веб-страница или CSS файл, например), то он будет обновлен в браузере. Кажется, я не нашел на это ответа, так что, возможно, я прошу слишком многого.
Вот мой VCL:
backend default {
.host = "public IP";
.port = "8080";
}
acl purge { "localhost"; "127.0.0.1";}
sub vcl_recv {
if (req.request == "PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
return (lookup);
}
#set req.grace = 60m;
if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") {
return (pipe); }
if (req.request != "GET" && req.request != "HEAD") {
return (pass); }
#if (req.http.Authorization || req.http.Cookie) {
#return (pass); }
return (lookup);
# Set X-Forwarded-For header for logging in nginx
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Remove has_js and CloudFlare/Google Analytics __* cookies and statcounter is_unique
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js|is_unique)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Either the admin pages or the login
if (req.url ~ "/wp-(login|admin|cron|cart|my-account|checkout|addons|administrator)") {
# Don't cache, pass to backend
return (pass);
}
if (req.url ~ "/administrator") {
return (pass);
}
if ( req.url ~ "\?add-to-cart=" ) {
return (pass);
}
if (req.url ~ "/(contact-us|contact|get-a-quote|upload-files|competition)")
{
return(pass);
}
# Never cache PUT, PATCH, DELETE or POST requests
#if (req.method == "PUT" || req.method == "PATCH" || req.method == "DELETE" || req.method == "POST") {
#return (pass);
#}
# Remove the wp-settings-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");
# Remove the wp-settings-time-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie,
"wp-settings-time-1=[^;]+(; )?", "");
# Remove the wp test cookie
set req.http.Cookie = regsuball(req.http.Cookie,
"wordpress_test_cookie=[^;]+(;)?", "");
# Static content unique to the theme can be cached (so no user uploaded images)
# The reason I don't take the wp-content/uploads is because of cache size on bigger blogs
# that would fill up with all those files getting pushed into cache
if (req.url ~ "lib/themes/" && req.url ~
"\.(css|js|png|gif|jp(e)?g)") {
unset req.http.cookie;
}
# Even if no cookies are present, I don't want my "uploads" to be cached due to their potential size
if (req.url ~ "/lib/uploads/") {
return (pass);
}
# any pages with captchas need to be excluded
if (req.url ~ "^/contact/" || req.url ~ "^/links/domains-for-sale/")
{
return(pass);
}
# Check the cookies for wordpress-specific items
if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") {
# A wordpress specific cookie has been set
return (pass);
}
# allow PURGE from localhost
if (req.request == "PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
return (lookup);
}
# Force lookup if the request is a no-cache request from the client
if (req.http.Cache-Control ~ "no-cache") {
return (pass);
}
# Try a cache-lookup
return (lookup);
}
sub vcl_fetch {
#set obj.grace = 5m;
#set beresp.grace = 60m;
}
sub vcl_hit {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
sub vcl_deliver {
# multi-server webfarm? set a variable here so you can check
# the headers to see which frontend served the request
# set resp.http.X-Server = "server-01";
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
}
Итак, в настоящее время лак удаляется в течение 5 минут, но мой максимальный возраст в .htaccess на сайтах составляет 3 секунды, что просто бессмысленно.
Я думаю в правильном направлении? Надеюсь, я понял. Надеюсь, кто-нибудь сможет показать мне свет!
Спасибо!
Поскольку вы используете Varnish, я бы посоветовал удалить ваши пользовательские заголовки кеширования .htaccess на бэкэнде и управлять заголовками кеширования из Varnish. Этот пример VCLExampleLongerCaching на сайте Varnish должен сделать это за вас правильно.
Я считаю, что curl очень полезен для отправки тестовых запросов на веб-сайты, чтобы увидеть, какие заголовки кеширования возвращаются. Вы можете сделать это, чтобы увидеть только заголовки, возвращенные для данного запроса:
curl -s -D - http://www.example.com -o /dev/null
Я попытался увидеть, есть ли способ иметь долгое время кеширования Varnish, тогда WordPress отправит заголовок, который он будет хранить в браузере в течение максимального возраста, скажем, 1 день, но если контент обновлен (веб-страница или CSS файл, например), то он будет обновлен в браузере.
Это очень распространенное требование, и сколько сайтов обрабатывает его, добавляя уникальный хеш в конец каждого URL-адреса файла CSS / JS в источнике страницы. Каждый раз, когда файл изменяется, меняется и уникальный хэш, так что у этого ресурса теперь есть новый некэшированный URL. Таким образом, вам просто нужно очистить HTML-страницу от Varnish, и любые изменения в ссылочных ресурсах будут обновлены автоматически. Похоже, что Wordpress тоже использует эту технику - я только что взглянул на случайный сайт Wordpress и увидел, что строка даты вроде «? V = 20150727» находится в конце каждого файла CSS в источнике.