Cache Vary Groups Behavior

yes, it varies even without ESI , but when no ESI, every login users have its own private cache, so it doesn’t really impact on anything

for guest user , it is vary-group’ed as “guest” , which falls back to public cache , when its login users , no matter what group this user belongs to , it has its own private cache.

Is the private cache served from the origin or QUIC.cloud CDN?

when its login users , no matter what group this user belongs to , it has its own private cache.

LightSpeed Cache states “When a page is privately-cached, there is a separate personalized copy stored for each user that requests it.”

• https://blog.litespeedtech.com/2017/08/30/wpw-private-cache-vs-public-cache/

Suppose that ESI is disabled and a cache vary is configured for three roles with 1000 users.

• Does this configuration store 1000 pages (one for each user) or does it store 3 pages (one for each role) in addition to the public cache page.

the cache is always generated from origin , and then it will be stored at QC and origin

if you have 1000 users visited one page, then it will be 1000 cache objects in total , one per each, and this is the reason why private cache has shorter TTL to conserve disk space.

the cache is always generated from origin , and then it will be stored at QC and origin

So QC will perform authentication for logged-in user on private cache page to serve private cache page without hitting origin?

How do you configure QC to store 3 pages (one for each role) in addition to the public cache page?

You must enable ESI?

If I enable ESI, then it only stores a section of the page and always hits origin server for rest? Or does it store everything on QC, then create the template in QC?

the login status is stored in cookie , so QC will check the cookie value as authentication , if this private cache is stored on QC already , then no hit on origin , if it was not , or expired , then hit origin.

yes , you must enabled ESI

if you enable ESI , the page for login user , on same group , will have one “login-user’s public cache” , and utilize ESI block to fill in the rest

this pub cache , presumably will be stored on QC , but for ESI blocks , it will be same case as aforementioned private cache situation.

there is nothing special about QC , for functionaility-wise, it is literally same as your origin’s LSCache engine , the only difference is the geolocation where the QC servers are placed , that is closer to end-users.

the login status is stored in cookie , so QC will check the cookie value as authentication , if this private cache is stored on QC already , then no hit on origin , if it was not , or expired , then hit origin.

qtwrk

This information contradicts what you said 2 months ago in this forum post.

How to perform authentication from the CDN level (without involving host server)?

featuremonkey

well, this is NOT possible , CDN is only a reverse proxy server + caching , it does NOT carry any PHP script of your site.

qtwrk

Moving forward, you have stated that the user must enable ESI to configure QC to store 3 pages (one for each role) in addition to the public cache page. However, the behavior you have provided does not match the behavior I am requesting.

if you enable ESI , the page for login user , on same group , will have one “login-user’s public cache” , and utilize ESI block to fill in the rest

qtwrk

So with ESI enabled, there will be two objects on QC (after the origin is visited): Public and Private Cache. When a logged-in user visits the website, QC takes the cookie to verify that user’s status, then takes the template private cache and fills it with an ESI block.

And that ESI block (e.g., headline for a logged-in role) is also stored on QC, so then QC doesn’t hit origin server to “fill” the page.

Is that correct?

If so, how do you configure QC to — instead of filling the template — just store 3 page objects (one for each role), and serve those pages accordingly without hitting origin server?

this pub cache , presumably will be stored on QC , but for ESI blocks , it will be same case as aforementioned private cache situation.

qtwrtk

The public cache you refer to is the “Private Cache” of all logged-in users with ESI enabled. So, does this statement mean that

1. ESI blocks will be cached per user (i.e 1000 esi cache block objects) on origin and QC?
2. ESI Blocks will be cached per role (i.e 3 esi cache blocks objects) on origin and QC?

there is no contradiction, but the term might be misunderstood here based on the context.

the QC CDN is a proxy, by that saying, it only forwards traffic from one point to another, in this context , we are talking about browser and origin server, it does NOT execute the PHP code , and in the world of wordpress, the PHP code checks for user identity

in this case , the private cache is linked/tied to a cookie value.

once the origin server authenticated user, origin will instruct browser to store a cookie, and sent out page with cache instruction header, QC will store that cache, and later on, assuming this private cache is not expired/purged, then, when a browser sends request with that given cookie, the QC will provide this private cache

QC itself does not do the authentication as check username/password against database , it checks/stores the result of authentication by cookie.

——–

yes , just say you have a page , 90% of its content is same for all roles , only 1 section, saying, a username-display, is private ESI block, then it will be (number of roles) public caches + (number of visited login users) private ESI blocks.

once the cache is generated on origin, and during the proxy to user , the CDN node that proxies the traffic , will also store a copy regardless if it’s private or public , normal or ESI.

——-

I am not exactly sure if I understand the question

———

if it’s private ESI , it will be per user , otherwise per role.

If so, how do you configure QC to — instead of filling the template — just store 3 page objects (one for each role), and serve those pages accordingly without hitting origin server?

featuremonkey

I am not exactly sure if I understand the question

qtwrk

Suppose that you have 3 + 1 roles:

• Admin
• Member A
• Member B
• (guest)

There is a page (with path /a-post ) with content that can be seen by both Admin and Member A, but not Member B or guest users.

When ESI is enabled, QC is still required to store lots of cache block objects for the page template (“public cache”; one for each role) and each user login (“private cache”; one for each logged-in user), then piece them together into a final page that is delivered to browser. However, this overhead is unnecessary in this scenario.

Instead, QC could theoretically generate 2 – 4 pages without ESI enabled for less overhead:

• Page (of path /a-post) output for Admin Role, Member A
• Page (of path /a-post) output of Member B, guest

*2 pages since the content has 2 variations; one for administrators and A members, one for B members or guests.

This theoretical setup only requires QC to store 2 pages (of path /a-post), instead of the discussed configurations where

• ESI Disabled, Cache Vary Disabled: 1 “public” page for guests, with thousands of “private” DUPLICATED pages (one for each user).
• ESI Disabled, Cache Vary Enabled: 4 useless “public” pages are created for each role, with thousands of “private” DUPLICATED pages (one for each user).
• ESI Enabled, Cache Vary Enabled: 4 “public” pages are created for each role, with thousands of “private” DUPLICATED esi blocks for each user, which are then formatted into a final page upon request.

So instead of storing thousands of duplicated cache objects with those configurations, “how do you configure QC to only store the 2 – 4 final cache page objects (one for each role = 4; or one for users with the right cookie and one for users without the right cookie = 2)” for the same path (example /a-post), and serve the correct page object accordingly without hitting origin server?

Instead, QC could theoretically generate 2 – 4 pages without ESI enabled for less overhead:

• Page (of path /a-post) output for Admin Role, Member A
• Page (of path /a-post) output of Member B, guest

yes, that’s very simplefied and optimal vision.

but how do you differentiate admin and member A in this case ? if use cookie , you are invoking the cache vary , that will make page to serve individually and privately to admin and member A , then we are back to the previous situation as a dead loop

or how do you detect member B and guest user ? in case to display login form, login link or something.

I mean , at certain point , you have to detect the user identify , like go to next/previous page , jump to account page …etc

and unfortunately you can’t , as plugin doesn’t work that way and what you asking is against plugin’s logic, or even wordpress’s logic.

When ESI is enabled, QC is still required to store lots of cache block objects

in case there is a lot of ESI block , and the main point for ESI is to make cache as publicly as possible to reduce whole page process time when encounter private content , instead of re-generating the whole page , but only invoke PHP to generate a small section of it.

certainly you can modify the plugin source code to “overcome” this limitation and forcefully to make this happen , but that’s really out of support scope.