Hi,
I have two identical drupal setups - one at pantheon (getpantheon.com) and one at gigahost.dk
As far as authcache goes I have enabled only:
1. Authcache
2. Authcache Builtin Storage Backend
3. Authcache Debug
Also, in both cases I use the most basic settings.php:
$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.cache.inc';
$conf['cache_backends'][] = 'sites/all/modules/authcache/modules/authcache_builtin/authcache_builtin.cache.inc';
So I am just trying to get basic page cache going. And on gigahost it works perfectly. On node/1 I get this the second time i load the page:
(green)
Status
Cache Status: "HIT"
Speedup: "6,544% increase"
Page Render Time: "1098.2 ms"
Cache Render Time: "16.53 ms"
Page Age: "6 seconds"
Wonderful.
On pantheon, however, I just get the following no matter how many times i reload node/1:
(Yellow)
Status
Cache Status: "MISS"
Page Render Time: "152.51 ms"
Page Age: "1 seconds"
So with two identical drupal setups, there seems to be something at pantheon "blocking" a HIT.
Anyone knows what could be going on?
I will also talk to pantheon support about this, but would like to hear if others have had the same experience as me.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | authcache-cookies_for_pantheon-2355055-7.patch | 3.64 KB | hanoii |
Comments
Comment #1
znerol commentedAuthcache Debug issues an Ajax request on every page load. Make sure this request is not cached somewhere, otherwise the widget will always indicate a miss.
I've just recently found a bug where the debug widget always would be reporting a miss when authcache was configured to cache XHR responses, commit 4a0fc1a fixed that.
Comment #2
lennart commentedThanks for replying.
When inspecting the response header for role authenticated user in the browser on the second page load it says :
X-Drupal-Cache:HIT
Does this mean that Authcache is actually working even though the Authcache Debug reports a MISS?
Comment #3
znerol commentedYes. The header value is reliable.
Comment #4
lennart commentedThank you very much.
Comment #6
lennart commentedComment #7
hanoiiFor what it's worth, I am facing this same issue and somehow found the culprit.
It seems than pantheon strips out some cookies on their Varnish edge. Now I can't seem to find this properly documented although there are some hints here:
https://pantheon.io/docs/varnish/
https://pantheon.io/docs/caching-advanced-topics/
https://pantheon.io/docs/cookies/
However, because the ajax debug call is not cached, I am unsure if pantheon should actually be stripping cookies at all, but this falls within their realm.
One "workaround" that I have made to work this with pantheon is to name the aucdbg cookie as Drupal.authcache.aucdbg. They seem to allow Drupal* cookies to pass-trough.
This is really a harmless change to authcache but I am not sure if this module should do something about it.
I am also not sure also if there are other cookies set by this module that could affect authcache proper functionality if they are not reaching. @znerol what do you think about this?
Anyway as a proof of concept this is a working patch that makes authcache_debug works with pantheon. I have submitted a support ticket with them and will try to update this as soon as I have some more/definite information.
Comment #8
znerol commentedWow! There is one cookie which is rather important for cache busting:
aucp13n. However if I'm not mistaken that cookie is only relevant on the client side (Ajax) since the value is added to fragment URLs.Comment #9
znerol commentedI can reproduce the issue now (using a local varnish with appropriate config). If Pantheon is indeed stripping all cookies except the session, the infamous
has_jsand cookies with aDrupalprefix, then this explains the reported behavior. Also it looks like the patch is resolving the issue, nice find!Comment #10
znerol commentedComment #12
znerol commentedThanks @lennart for reporting this issue and @hanoii for finding the reason and providing a patch.