The documentation and help text both state the following:

On the Performance (admin/config/development/performance) page, you can configure how long browsers and proxies may cache pages. That setting is also respected by the Internal Page Cache module.

I read that to mean that if you set the page cache max age (cache.page.max_age in the system.performance configuration) to then cached paged responses will not be generated (or at least not served), even if the Internal Page Cache module is on. Likewise, I read that to mean setting this to "1 min" will but an expire time on the cached page responses of 1 minute, but that's not true either.

What this setting does do is simply affect how the cache control headers are set on the response, which affects proxies like Varnish and client caches like a browser cache.

In fact, page cache responses are always set to have an expiration of -1, meaning they will never be invalidated organically over time without some cache purging event. This behavior led to lots of confusion in the community.

There is a large core issue #2526150: Database cache bins allow unlimited growth: cache DB tables of gigabytes! in the works to make page cache entries have an expiration, but the current patch there does not use the max age configuration setting anyway.

I'm suggesting that we update the documentation and help text, and perhaps update the performance form to be clearer about how this setting affects internal page cache behavior.

CommentFileSizeAuthor
#10 2862894-internal_page_cache-10.patch1.81 KBfgm
#8 2862894-page_cache_help-7.patch1.81 KBfgm
#5 2862894-page_cache_help.patch1.82 KBfgm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bkosborne created an issue. See original summary.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Issue summary: View changes
Issue tags: +Documentation, +DX (Developer Experience)

Clarifying IS slightly.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

In fact, page cache responses are always set to have an expiration of -1, meaning they will never be invalidated organically over time without some cache purging event. This behavior led to lots of confusion in the community.

Agreed.

The reason it always sets -1 is that responses are assumed to remain the same until a cache tag that is associated with the response gets invalidated. But, of course, browsers/proxies A) generally do not support cache tags, B) we would have no way to inform them all that some cache tag was invalidated.
Therefore Page Cache indeed only has one mechanism with which to ensure that browsers/proxies don't cache responses for too long: the "max age" setting in system.performance.

Agreed that we should update the documentation and help text.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm as a volunteer and at OSInet for Carrefour commented
Status: Active » Needs review
FileSize
2862894-page_cache_help.patch1.82 KB

How about this ?

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Status: Needs review » Reviewed & tested by the community

👍

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented 
+++ b/core/modules/page_cache/page_cache.module
@@ -23,7 +23,7 @@ function page_cache_help($route_name, RouteMatchInterface $route_match) {
+      $output .= '<dd>' . t('On the <a href=":cache-settings">Performance page</a>, you can configure how long browsers and proxies may cache pages based on the Cache-Control header; that setting is ignored by the Internal Page Cache module, which caches pages until permanently until invalidation, unless they carry an Expires header. There is no other configuration.', [':cache-settings' => \Drupal::url('system.performance_settings')]) . '</dd>';

which caches pages until permanently until invalidation does not look right.

I think the first until should be removed?

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm as a volunteer and at OSInet for Carrefour commented
FileSize
2862894-page_cache_help-7.patch1.81 KB

Indeed it should.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Status: Reviewed & tested by the community » Needs review 
+++ b/core/modules/page_cache/page_cache.module
@@ -23,7 +23,7 @@ function page_cache_help($route_name, RouteMatchInterface $route_match) {
+      $output .= '<dd>' . t('On the <a href=":cache-settings">Performance page</a>, you can configure how long browsers and proxies may cache pages based on the Cache-Control header; that setting is ignored by the Internal Page Cache module, which caches pages permanently until invalidation, unless they carry an Expires header. There is no other configuration.', [':cache-settings' => \Drupal::url('system.performance_settings')]) . '</dd>';

I'd probably go for 'this setting' or 'the setting' rather than 'that setting', since there's only one setting being talked about.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm as a volunteer and at OSInet for Carrefour commented
FileSize
2862894-internal_page_cache-10.patch1.81 KB

So be it.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented
Status: Needs review » Reviewed & tested by the community

Looks good.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach as a volunteer commented
Version: 8.4.x-dev » 8.5.x-dev

This will have to go in 8.5.x first.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach as a volunteer commented
Issue tags: +String change in 8.5.0

Unfortunately this is a UI string change so I don't think it can be backported to 8.4.x.

(Also saving credits)

  • plach committed efab31b on 8.5.x 
    Issue #2862894 by fgm, Wim Leers, bkosborne, borisson_, catch: Docs for...
plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach as a volunteer commented
Status: Reviewed & tested by the community » Fixed

Committed efab31b and pushed to 8.5.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.