Configuring Nginx and Pagespeed to serve cached files

[Martin Patzekov]

Hi guys,

I was wondering something and I will really appreciate it if someone knows how to achieve the thing that I will describe below. 

So, here we go. Before I tell you anything, I will say that I am focusing to use ngx_pagespeed only for caching images. Actually, compressing images, caching them and serving them to the users that request the original images, of course .... keeping the urls unchanged.

Currently, the ngx_pagespeed is working the following way:

1. User 1 requests the images (request 1) ---> nginx gets the request ---> the original images are served to User 1 --- > ngx_pagespeed compresses the images and stores them for later requests

2. User 1 requests the images again (request 2) ---> nginx gets the request ---> compressed images are served to User 1

3. User 2 requests the images (request 3) ---> nginx gets the request ---> the original images are served to User 2 --- > ngx_pagespeed compresses the images and stores them for later requests

All requests are made in a 1-2 minutes interval.

And here is the conflict. Why the cached images are not served to User 2, once they are generated from the request of User 1 and stored locally as compressed images? 

I am not sure if I could describe the issue very well, but I hope you will get the idea. Does somebody know how this can be fixed? And do you need my config files? 

Thanks a lot for the help! 

[Joshua Marantz]

You described the issue perfectly, and I think I can help explain what's going on.  First, I'm going to assume that you configured ngx_pagespeed with

  pagespeed level OptimizeForBandwidth;

is that what you have?   That's the simplest way to configure PageSpeed for this use-case.

First: I think it's worth pointing out that it's unlikely that User 1 would get the optimized result on the second view; it's more likely it would be on the third, due to the way in-place optimization works:

1. First request: image is captured unoptimized and saved in PageSpeed's cache; original image is sent to browser.
   
2. Second request: image is optimized based on parameters of the browser doing the request; original image is again sent to browser
   
3. Third request: optimized image is sent.
   

So the second question is whether User 1 and User 2 have the same browser properties.  There are three interesting properties in terms of how images are compressed;

• Does the browser support webp images or not (ie is the browser Chromium-based)
  
• Is it a mobile browser?
• Has the user turned on data-saving features in the browser?  This adds a "Save-Data" request header, and is enabled with the Chrome data-saver option.

Depending on these options, there may be several different ways to optimize the same image, so if User 1 and User 2 are on different browsers, the optimization step may need to be repeated.  In this case, the origin image may not need to be refreshed (depending on its TTL, and we can just repeat steps 2 & 3 above based on new browser parameters.

Hope this helps!

-Josh

--
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.

[Martin Patzekov]

Aha, I see. So basically, the pagespeed module works as expected and I should leave it this way. Yes, you are right that I am using OptimizeForBandwidth. I can also confirm that the steps you described - 1,2 and 3 - this is exactly how the module behaves.

From everything said above, I understand that I should just leave the module to cache as much scenarios as possible. Then.. when a new user comes and his user-specific metrics match the settings of a similar user that hit the website before, then the new user will be directly served the cached images, right?

Just to add, to ensure preserving the cached files for a long time, I have put a large value to this configuration parameter - pagespeed FileCacheCleanIntervalMs   604800000;

[Longinos]

Hi

I think no, this param (pagespeed FileCacheCleanIntervalMs   604800000;) is only to say when the clean process is run, not to say how much time a cache object stay in the cache system. This is achieved in 2 ways: TTL of the request (if feched by http) or LoadFromFileCacheTtlMs if LoadFromFile is used.
If http is used but no TTL are stablished, you can use the ImplicitCacheTtlMs directive.

[Joshua Marantz]

Thanks Longinos.

The file-cache clean interval determines how often eviction is attempted.  Eviction only occurs if you are out of space.

The time-to-live of various resources is entirely separate from eviction.  Whenever a cache element is physically present, it is checked to see if it is past its expiration date, based on HTTP Cache-Control:max-age= or Expires: headers, or the option overrides as Longinos indicated.

Note that optimized resources have an expiration time of 1 year.  I have an ancient but maybe-still-helpful blog post that goes into detail about this: http://modpagespeed.jmarantz.com/2012/12/caching-in-modpagespeed.html

-Josh