У меня были очень хорошие результаты при использовании Микрокэширование NGINX.
Однако я все еще не уверен, как лучше всего обрабатывать ответы сервера с Set-Cookie заголовок.
Set-Cookie заголовок вообще кешируется NGINX?Если ответ отрицательный и Set-Cookie ответы всегда должны обходить уровень кеширования, это может иметь очень негативные последствия для производительности.
Например, когда вы посещаете средний сайт электронной коммерции с WooCommerce, эти файлы cookie будут установлены при вашем первом посещении:
Установить файл cookie: PHPSESSID = xxyy
Set-Cookie: wp_woocommerce_session_xx = yy
Должен Set-Cookie ответы будут исключены из кеширования, это будет означать, что кэшированный контент никогда не будет обслуживаться при первом посещении любого магазина электронной коммерции.
Кроме того, при просмотре продуктов в магазине WooCommerce плагин установит woocommerce_recently_viewed=xxxx куки. woocommerce_recently_viewed cookie будет обновляться при каждом просмотре продукта, поэтому все последующие запросы к другим продуктам заставят сервер включать Set-Cookie заголовок.
Некоторая конфигурация кеширования по умолчанию, которую я использую с моим NGINX, включает следующее:
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
Если я включу woocommerce_recently_viewed cookie в списке, кеш большую часть времени будет обходиться.
В целом кеширование плохо работает с динамическим контентом, особенно с контентом, который содержит такие вещи, как «недавно просмотренные», которые изменят загрузку каждой отдельной страницы. Если вы действительно хотите использовать кеширование, первым делом необходимо отключить этот плагин, чтобы теоретически была вероятность того, что кому-то может быть предоставлена одна и та же страница дважды. Второй шаг - запускать сеанс только тогда, когда кто-то делает что-то, что требует этого: входит в систему, кладет товар в свою корзину и т. Д. С этого момента вам придется прекратить кеширование после создания файла cookie сеанса (в противном случае, если клиент попадает в кеш только на время, сеанс истекает как на стороне клиента, так и на стороне сервера).
Я думаю, что для такого контента кеширование лучше всего делать в самом приложении. Приложение должно понимать, какие части веб-страницы являются динамическими и должны обновляться при каждой загрузке страницы, и может собирать веб-страницу из новых и использованных частей, чтобы дать пользователю правильный ответ.
DerfK прав насчет динамического контента на Полная страница уровень, вы абсолютно не хотите, чтобы произошла утечка файлов cookie.
Однако вы можете сделать больше кэширования на уровнях вверх по течению - в частности, в WordPress есть достойный подключаемый кеш объектов. Это означает, что, хотя сама страница не будет кэшироваться, вы можете хранить большую часть нагрузки базы данных в эфемерном хранилище, таком как memcached (batcache) или redis. Эти хранилища KV работают намного быстрее, чем MySQL, и, поскольку они работают на уровне объекта и приложения, файлы cookie, отправляемые WooCommerce, не влияют на них напрямую.