Open michael-rubel opened 4 years ago
The github repo is open and we would welcome PRs to improve the product. Are you interested?
Agreed there is a ton to do.
I thought it is supported by Google and isn't by the community. Looks like I don't have enough skill in C to improve this product, but I can tell the direction in which it may go in the future just because I tested a lot of things using it as web developer/admin.
We're working to produce an apache incubator release for mod_pagespeed; updating ngx_pagespeed to leverage that new version and ship a new release based on that will be low hanging fruit.
Glad to hear that work in progress. What about moving downstream caching from "experimental" to "prod-ready" at least with the most popular Varnish HTTP Accelerator? You probably will tell me that it's ready and documented, but we have some fundamental problems with that in production.
As far as I know no one is planning to mark that as production ready at this time, mostly because it’s not clear how many people are running that in production. What kind of trouble did you run in to in production? If it’s fixable in VCL then arguably it might be a documentation fix or extension, which would be very welcome! :)
It looks like a problem in the way PageSpeed purging the content from Varnish. At the start, its behavior is like described on the image in documentation: https://www.modpagespeed.com/doc/downstream-caching
But next, it's randomly purging (after 5 or more minutes of serving cached content) the cache from Varnish and we getting cache misses when TTL is set to 24h.
I think cacheability of the html is restricted to the recursive minimum of all resources included in the page, by nature of how the module works (if resources urls are rewritten to .pagespeed. variants). 404s will count as 5 minutes by default, so these could degrade html cacheability, also when included indirectly via css.
On Fri, 31 Jan 2020 at 02:22, observer.name notifications@github.com wrote:
It looks like a problem in the way PageSpeed purging the content from Varnish. At the start, its behavior is like described on the image in documentation: https://www.modpagespeed.com/doc/downstream-caching
But next, it's randomly purging (after 5 or more minutes of serving cached content) the cache from Varnish and we getting cache misses when TTL is set to 24h.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-pagespeed-ngx/issues/1678?email_source=notifications&email_token=AARCYRFB4RMTWZEWYOVGCALRAN4N7A5CNFSM4KN6OD6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKNFCWY#issuecomment-580538715, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCYRAJY5B5PFBVFF6OTF3RAN4N7ANCNFSM4KN6OD6A .
One thought -- can't remember what the code state is -- if we are using OptimizeForBandwidth for assets, we don't need to include them in the MIN for computing the HTML cacheability, whether they are 404 or successful.
I think cacheability of the html is restricted to the recursive minimum of all resources included in the page, by nature of how the module works (if resources urls are rewritten to .pagespeed. variants). 404s will count as 5 minutes by default, so these could degrade html cacheability, also when included indirectly via css.
Can we workaround this in some way?
Well jmarantz suggested OptimizeForBandwidth, which I think is easy to do.
Or possibly one could add some nginx configuration to transform resource response headers to override origin cache TTL before pagespeed gets to see them, if .pagespeed. rewriting is a must. Plus configure pagespeed to cache 404s longer then 5 minutes.
Otto
On Sun, 2 Feb 2020 at 00:42, observer.name notifications@github.com wrote:
I think cacheability of the html is restricted to the recursive minimum of all resources included in the page, by nature of how the module works (if resources urls are rewritten to .pagespeed. variants). 404s will count as 5 minutes by default, so these could degrade html cacheability, also when included indirectly via css.
Can we workaround this in some way?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-pagespeed-ngx/issues/1678?email_source=notifications&email_token=AARCYRCJ3OXYFMPFHXTLCSDRAYCFBA5CNFSM4KN6OD6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRJRJA#issuecomment-581081252, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCYREHLLEZURJTRWDUM4LRAYCFBANCNFSM4KN6OD6A .
Well jmarantz suggested OptimizeForBandwidth, which I think is easy to do.
I tried OptimizeForBandwidth, but it behaves the same way in this case.
We're working to produce an apache incubator release for mod_pagespeed; updating ngx_pagespeed to leverage that new version and ship a new release based on that will be low hanging fruit.
I see v1.14.36.1 released 17 days ago.
@oschaaf, if this is a stable release, can we expect a new release for Nginx sometimes soon?
1.14.36.1 got tagged, but has not been released yet, even though it did get approval by the incubator PMC: While finalizing the release steps, a blocking issue was observed in the scripts that create .deb/.rpm packages. I'm working on that.
Any updates on that? ;)
Yes, the last RC for PageSpeed (incubating) 1.14.36.1 was approved by the general incubator pmc: https://dist.apache.org/repos/dist/dev/incubator/pagespeed/1.14.36.1-rc5/
Just need to copy these to the official release location and finalize the release process. I'll try to do get that done in a couple of hours from now. Updating ngx_pagespeed to use this new release should be a fairly low effort operation.
X-posting from https://groups.google.com/g/mod-pagespeed-announce
PageSpeed represents a series of open source technologies to help make the web faster by rewriting web pages to reduce latency and bandwidth.
Artifacts from this release are available for download via: http://pagespeed.incubator.apache.org/doc/download
Release notes:
ASF PageSpeed (incubating) slack channel: https://the-asf.slack.com/archives/CJTG9RH9U
Otto van der Schaaf, on behalf of the Apache PageSpeed (incubating) community.
I see only one commit past year nad it was just a fix... This project is "finished" and we have to abandon it in the future? Just because standards of the web changing a bit fast and it has no support?