disable pagespeed cache?

[ashly]

Hi 

Is it possible to disable pagespeed cache?

Our pagespeed server  is in behind of another cache server(CDN). 

According to pagespeed documents, it must Local Cache to  convert or optimize html ,css ,js and image.

So, I am currently considering to another some pagespeed options that disable cache.

Ex:

FileCacheSizeKb and pagespeed FileCacheInodeLimit set value of 1 or minimum,  (it does not optimize.)

FileCacheCleanIntervalMs set value of 1000 (per 1sec )  

Does anyone know good idea ? 

Best regards.

[Joshua Marantz]

Good question: the short answer is "no", not currently. It is possible to enhance pagespeed to allow it to be configured to cache a lot less data, but that's not possible today with any existing options.

As you've observed, set the cache very small and PageSpeed won't optimize your website, but it will spend lots of CPU attempting to optimize on every request, and then forgetting the results the next time it gets a request and doing it all again. And if you set the cache clean-interval very small, it will also keep the disk subsystem very busy, cleaning the cache of anything written there in the last second :)

It's a very good point though, that PageSpeed's HTTP cache is somewhat redundant with a downstream cache like a CDN or Varnish, and it would make sense if we could disable the HTTP cache.  However, PageSpeed's operation critically depends on a metadata cache and, to a lesser extent, a property-cache.  The metadata cache tells PageSpeed "I've seen foo.jpg before, and I I've already optimized it for the current browser (say mobile Chrome), renaming it to (say) foo.jpg.pagespeed.ic.hash.webp".  If that metadata cache always fails (returns a MISS), PageSpeed will have to re-optimize the image. Basically it's a non-starter IMO. However, the metadata cache is very small relative to the HTTP cache.

We could in principle disable the HTTP cache. There's no way to configure that now, but it might not be that hard to add. I haven't fully thought through what happens if we do that.  One disadvantage is that we'd have to do more internal fetches.  For example, the same source image, foo.jpg, may need to get optimized up to 8 different ways: for (mobile | desktop) * (webp | non-webp) * (save-data | not-save-data). Currently it just gets fetched from origin once, and saved in PageSpeed's HTTP cache, from which it could get optimized on-demand for all 8 possible client combinations. In the absence of an HTTP cache, that all still works, but it would just have to fetch the origin resource each time, until the metadata cache was warm.

InPlaceResourceOptimization would also stop working (unless LoadFromFile was enabled).  This is because InPlaceResourceOptimization for ngx_pagespeed and mod_pagespeed both work by collecting origin resources as they stream through the output filter, and saving them in the HTTP cache.  The image/css/javascript optimizers don't kick in until the image is in the cache. I think it might be possible to change to buffer the resources and optimize them in-stream, but that would be a fairly significant change.

There's also the property-cache, which helps with prioritize_critical_css, inlining images that are above-the-fold, and a few other cases.  That's similar to the metadata cache -- a CDN's cache wouldn't really help for either of those.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.
Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

[ashly]

Hi thank you for the answer and detail.

but it will spend lots of CPU attempting to optimize on every request.

and then forgetting the results the next time it gets a request and doing it all again.
And if you set the cache clean-interval very small, it will also keep the disk subsystem very busy, cleaning the cache of anything written there in the last second :)

I think you're right. if pagespeed did not cached, spend lots of CPU and DISK cost.

But in case configured the CDN or varnish in front of pagespeed,  second request is not came into pagespeed because varnish or CDN is cached of first request. 

In addition,it should be cache management both CDN(varnish) and pagespeed.

When cache separate per browser or other situation, It is better to leave it to the upstream cache server by Vary header of PageSpeed.

I think pagespeed need to no-cach options so as to simple cache control when using CDN or another cache.

2018年5月23日水曜日 21時45分48秒 UTC+9 Joshua Marantz:

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

[Joshua Marantz]

So...yes, that can be done (simple matter of coding).  But what is that you are trying to fix or optimize?  I don't think PageSpeed's cache is getting in the way functionally, right?

I'm assuming you are concerned about the resources PageSpeed's cache consumes.  As I've noted, the metadata and property caches are much smaller than the sometimes-redundant http cache.  And as you've observed, the CDN in front of PageSpeed will protect PageSpeed from seeing requests for optimized resources, at least after the first request.  Thus there will not generally be recent references for resources captured in the CDN.

Then, the file-cache will periodically wake up and clear the old data as needed, so I think the system will naturally take the optimal shape.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

[ashly]

hi.

I would like to optimize rewrite_css, js also image without rewriting URL.

> I don't think PageSpeed's cache is getting in the way functionally, right?

yes, but I am apprehensive about 2 issue. (I think resources PageSpeed's cache consumes is no problem),

1:countents update

when contents is updated. the user should twice request of purge (CDN and Pagespeed)

2:Optimize

the first request, PageSpeed delivered not optimize contents if optimize slow or contents is big size.

After first request, PageSpeed deliver optimize contents.

In case of CDN, first response(not optimize) is already cached, CDN is no fetch pagespeed servers.

So, CDN must handled cache control using x-original-content-lenght header.

if you have more simply solution, please advice me.

2018年5月25日金曜日 2時32分49秒 UTC+9 Joshua Marantz:

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

[Joshua Marantz]

To rewrite contents without rewriting URLs, the easiest way is to use 

ModPagespeedRewriteLevel OptimizeForBandwidth

To have ngx_pagespeed help you with purging downstream caches, please read:

https://www.modpagespeed.com/doc/downstream-caching

I am interested in why you want to avoid rewriting URL though, because that might actually help you with the purging problem. If you allow pagespeed to rewrite URLs, you don't have to worry about purging CDN caches, because the URLs will change whenever PageSpeed determines the content changed.  There are sometimes good reasons to avoid having PageSpeed change URLs, but as you can see it makes some things harder, and limits PageSpeed's ability to optimize your site.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

[ashly]

Hi 

thank you for information. and sorry delay replying. Because I am trying OptimizeForBandwidth and downstream cache.

Is my understand correct about downstream cache ?

Downstream flow

Client -- varnish(CACHE) -- Nginx(PageSpeed) -- Origin

If PageSpeed is optimized finish, pagespeed send purge request to Varnish.

But it seems that PageSpeed does not sent  Purge request to Varnish.

pagespeed DownstreamCachePurgeLocationPrefix "http://localhost/";
pagespeed DownstreamCachePurgeMethod "PURGE";
pagespeed DownstreamCacheRebeaconingKey "test";

 If I check Varnish logs, PURGE logs did not shown.

And I don't know What is the purpose of　DownstreamCacheRebeaconingKey.

When PageSpeed get PS-ShouldBeacon : "secret-key"  header that PageSpeed send Purge request?

I am interested in why you want to avoid rewriting URL though, because that might actually help you with the purging problem. If you allow pagespeed to rewrite URLs, you don't have to worry about purging CDN caches, because the URLs will change whenever PageSpeed determines the content changed.  There are sometimes good reasons to avoid having PageSpeed change URLs, but as you can see it makes some things harder, and limits PageSpeed's ability to optimize your site.

the reason of client contents issue (HTML cache and sensitive Javascript). 

if it can be rewrite URL, as you said I don't have worry about purging cache.

2018年5月28日月曜日 22時51分53秒 UTC+9 Joshua Marantz:

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.