AAM: how to cache home page? (when path = /)

More information: it looks like the home page does get cached, just not on the first hit. However, I have "Cache content on first hit" enabled on the leaf node "Pages" (and in every other place).

Can you try with a custom web acceleration caching policy based on the AAM default “Complete” policy type and see if the / page is cached?

Digging a little further. Here are the debug headers. Looks like it's classifying the resource properly, even the first time.

uncached:
[V2.S10202.A34484.P65790.N13710.RN0.U1555833138].[OT/html.OG/pages].[P/0.1].[O/0.2].[EH8/20].[DH1/0].[C/Mk.0].[K/n]

cached:
[V2.S10101.A34484.P65790.N13710.RN0.U1555833138].[OT/html.OG/pages].[P/0.1].[O/0.2].[EH9/22].[DH2/2].[C/D0.0].[K/n]

That is by design. Check your S codes: S code definitions

S10201: Response was served from the origin web server, because the request was for new content.

When the BIG-IP receives a request for new content, it sends the request to the origin web server and caches the content before responding to the request. Future requests for this content are served from cache.

And this SOL: SOL10569: BIG-IP WebAccelerator X-PvInfo response headers may demonstrate inconsistent object cache promotion sequence

Looks like I'm getting somewhere. I figured that it would always cache upon first request and thus show "Age: 0". However, that doesn't seem to be the case.

wainfodecode "[V2.S10202.A34484.P65790.N13710.RN0.U1555833138].[OT/html.OG/pages].[P/0.1].[O/0.2].[EH8/20].[DH1/0].[C/Mk.0].[K/n]"
V2: X-WA-Info Format Version
S10202: Response was served from the origin web server, because the cached content had expired.
A34484: Application: /Common/www.domain.com_aam_custom
P65790: Local-policy: /Common/www.domain.com_custom
N13710: Request Policy Node: Pages
RN0: Response match did not supersede request match
UCI hash: 5cbc2132
Object type: html
Object group: pages
Request served from TMM: 0.1
Request owned by TMM: 0.2
Entity hit count (local/remote): 8/20
Document hit count (local/remote): 1/0
Document in memory/small object cache.
Reason: Usable content received.
Bypass: Not applicable.
Parking: Not parked.

If you are using the RAM only cache it is a design feature since there is only so much RAM to go around to selectively cache things based on utilization even if they are valid caching entries. I was looking for some documentation to back that up but I can't find it. I was on a call about 8 months ago with a NSE and he was talking about it. Let me look some more.

I think what you are seeing is what is in SOL10569: BIG-IP WebAccelerator X-PvInfo response headers may demonstrate inconsistent object cache promotion sequence . They changed the header name in AAM but the sequence should still be the same.

The expected object promotion sequence through the different caches is as follows:

• The initial request for a cacheable object received by the BIG-IP LTM is passed to the BIG-IP WebAccelerator and proxied to the origin server. The response from the origin server is served to the client with an S10201 X-PvInfo header code and cached to the BIG-IP WebAccelerator cache, or Smart Cache disk.
• When the next request for the object is received by the BIG-IP LTM and passed to the BIG-IP WebAccelerator, the object is served to the client from Smart Cache with an S10102 X-PvInfo header code and promoted to memory Smart Cache.
• When the next request for the object is received by the BIG-IP LTM and passed to the BIG-IP WebAccelerator, the object is served to the client from memory Smart Cache with an S10101 X-PvInfo header code and promoted to the BIG-IP LTM RAM Cache.
• Subsequent requests for the object received by the BIG-IP LTM are served directly from the BIG-IP LTM RAM Cache with an S11101 X-PvInfo header code and not passed to the BIG-IP WebAccelerator until the RAM Cache maximum age is reached.

@Brian,

Thanks for digging that up!