New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cache-purging does not work for in-place resource optimization #1192

Closed
deweydb opened this Issue May 9, 2016 · 14 comments

Comments

Projects
None yet
4 participants
@deweydb
Copy link

deweydb commented May 9, 2016

I've tried both via ssh and also via /pagespeed_admin/cache#purge_cache
When i click the "purge entire cache" button it says "Purge successful" I can see that the timestamp on the cache.purge file has changed, but all old files still persist.

Could this be permissions related? Is there some place that failures to delete files from the /v3/ folder are logged?

I experience the same behaviour when trying to purge individual files as well.

Any help greatly appreciated!

Configs:
server:
https://p.ngx.cc/317bf88f36c6648a
host:
https://p.ngx.cc/8b9605488d0773f9

@oschaaf

This comment has been minimized.

Copy link
Member

oschaaf commented May 9, 2016

Purging the cache does not physically remove the current pagespeed-cache files from disk (but all the the entries that exist at the time of purging will be considered stale).

Assuming that answers your question, I'm closing this - but please re-open if you actually have a problem with stale content being served!

@oschaaf oschaaf closed this May 9, 2016

@deweydb

This comment has been minimized.

Copy link

deweydb commented May 9, 2016

Hi Otto,

Yes, stale content continues to be served. The only way i have been able to get it to stop serving stale content is to literally delete my entire cache folder. i.e. the folder defined at: "pagespeed FileCachePath /var/ngx_pagespeed_cache;"

Something like:

service nginx stop
rm -Rf /var/ngx_pagespeed_cache
service nginx start

@oschaaf oschaaf reopened this May 9, 2016

@oschaaf

This comment has been minimized.

Copy link
Member

oschaaf commented May 9, 2016

Looking at the configuration you posted, you are also using downstream caching.
Did you purge the proxy cache as well?

@deweydb

This comment has been minimized.

Copy link

deweydb commented May 9, 2016

Yes.

@deweydb

This comment has been minimized.

Copy link

deweydb commented May 9, 2016

So, if i understand this correctly, the intended functionality is that stale cache items remain on disk even after cache purge. I presume nginx page speed module does some sort of check to see if this item is stale, before re-serving the file from disk, and instead generating a new file. What is this check? is it based on dates? Perhaps nginx_page_speed module is operating on a different clock setting than my system?

When a stale cache file is detected, and requested again from the browser, what is the intended behaviour? is this file deleted and re-created? or is an entirely new file created, and the old file remains? Is there any way to see logs of these actions, delete, create, overwrite actions that occur in the cache folder? I believe this will lend a lot of insight into what the root of the problem is.

@deweydb

This comment has been minimized.

Copy link

deweydb commented May 9, 2016

An example can be seen here:
https://www.tivoresearch.com/contact/
Please note the CSS rule that is making the blue text in the black box have an underline is:
#map-info-box .address-body a{
text-decoration: underline;
}
This css is actually commented out, as can be see by requesting the document with a pagepseed bypass:
https://www.tivoresearch.com/wp-content/themes/TiVo/style.css?PageSpeedFilters=none
But if you request this file directly:
https://www.tivoresearch.com/wp-content/themes/TiVo/style.css
you will see that the file served is stale.

Before sending this message I have cleared the nginx proxy. And then also I have "purged the entire cache" from pagespeed_admin.

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 9, 2016

Possibly related to #1172 which was being investigated.

Also one nit: touching 'cache.purge' does nothing, and isn't supposed to; the timestamp of the purge file is not significant. However in the notes, it was indicated that the purge button was pushed in the UI, and that should work.

Current suspicion; the cache-invalidation records are not being passed through the stack properly in the ipro-path in nginx. Investigating.

@jmarantz jmarantz self-assigned this May 9, 2016

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 9, 2016

deweydb: can you work around this problem by turning in-place resource optimization off?
pagespeed InPlaceResourceOptimization off

@deweydb

This comment has been minimized.

Copy link

deweydb commented May 9, 2016

Awesome! that totally fixed it! would have never thought to do that! thank you so much!

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 9, 2016

Glad that worked around your problem :) This is a problem with cache-purging in ngx_pagespeed for in-place resources.

It is not a problem for in-place resources in Apache mod_pagespeed, and it is not a problem for .pagespeeed.-rewritten resources in nginx. But we lacked testing for the above combination. I'm working on getting a system-test now.

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 10, 2016

I have a repro now in system/system_test.sh -- passes on Apache and fails on nginx.

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 10, 2016

fix in review/test: #1193
test is in separate repo: apache/incubator-pagespeed-mod#1303

@jmarantz jmarantz changed the title touching cache.purge does not clear cache (no files deleted from cache folder) cache-purging does not work for in-place resource optimization May 13, 2016

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented May 13, 2016

renamed bug. old name: touching cache.purge does not clear cache (no files deleted from cache folder)

This is now fixed with tests in the nginx system tests.

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Jun 28, 2016

Looks like this was fixed with be78375

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment