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

Document ModPagespeedRewriteDeadlineMs #570

Closed
GoogleCodeExporter opened this Issue Apr 6, 2015 · 21 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Apr 6, 2015

Ver: trunk 2182

Using as a proxy server for browser, when open a new webpage at first time, no 
images shown in compressed, but when I open this webpage in other browser 
again, compressed images shown in magic.

If this is not a bug but a feature(cache?), can you make a way to let 
compressed images loaded at first time page view?

Original issue reported on code.google.com by kri2183...@maricopa.edu on 14 Nov 2012 at 7:26

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Is your goal to optimize for bandwidth, rather than optimizing for latency?  
We'd love to hear more about your use model.

This is feasible; it's just not what we are optimized for right now.

Original comment by jmara...@google.com on 14 Nov 2012 at 7:39

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

If we are using modpagespeed for proxy, I think it's very important to reduce 
the images size ASAP, because most of images are so over size(some of them we 
even don't care at page viewing), this will benefit page's loading time 
especially in low speed link condition like mobile network. 

It must be at a very low rate of cache hit because it's a proxy for many many 
different pages from different sites, so why we cache the compressed images for 
may-never-be-viewed-again pages?

Saving bandwidth may still be very useful in mobile network also, benefit 
latency a lot.

Original comment by kri2183...@maricopa.edu on 14 Nov 2012 at 8:12

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

This is similar to 
http://00f.net/2012/06/02/mod-pagespeed-as-a-proxy-for-your-phone/

This doesn't really answer your question; I'm just pointing you to some similar 
work.

If you can build from source, one thing you can experiment with is increasing 
the deadline for serving requests with a simple edit to 
net/instaweb/rewriter/rewrite_driver.cc line 149.

Change
  const int kOptWaitForRewriteMsPerFlush = 10;
to
  const int kOptWaitForRewriteMsPerFlush = 2000;

And now you are letting mod_pagespeed wait up to 2 seconds to make sure images 
are optimized before delivering HTML to the client.

This is not the optimal behavior, for a few reasons, but it might help.  We are 
thinking about broader solutions to tune the module for use in forward proxies, 
but this will take more time.


Original comment by jmara...@google.com on 14 Nov 2012 at 8:23

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

We have the X-PSA-Blocking-Rewrite header, do we have an option to force all 
HTML requests to block on sub-resource rewrite?

Original comment by sligocki@google.com on 14 Nov 2012 at 8:28

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

We got lazyload_images filter, can we just delivering HTML ASAP, then wait for 
images compressed?

Original comment by kri2183...@maricopa.edu on 14 Nov 2012 at 8:37

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Don't forget the slow down caused by having to wait for the image to be 
rewritten. What is the point of waiting 2 seconds to reduce an image by 90% if 
it would only take 1 second to download the original?

mod_pagespeed's general philosophy is to try to not make things -worse-, and 
although there are situations where it is better to wait, knowing which is best 
for any random request is far from trivial and often not decidable.

But, as Josh points out, if you -know- you are going to be serving to slow 
bandwidth devices (such as from an m. domain) there are ways to coax 
mod_pagespeed into doing more of what you need.

Original comment by matterb...@google.com on 14 Nov 2012 at 8:45

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Yes, it's easy to know which devices to server ( by UA ), but even we know 
this, how to conf mod_pagespeed into doing more compressed works?

Original comment by kri2183...@maricopa.edu on 14 Nov 2012 at 9:35

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

UA does not reliably tell you the bandwidth a device has available.
A mobile phone on 3G is bandwidth constrained, but the same device using wifi 
is not.

See Josh's comment (#3) 
http://code.google.com/p/modpagespeed/issues/detail?id=570#c3 for how to tweak 
mod_pagespeed.

Original comment by matterb...@google.com on 14 Nov 2012 at 9:47

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Following Josh's comment to tweak mod_pagespeed breaks whole proxy, oops, any 
page can't be load at all :|

Original comment by kri2183...@maricopa.edu on 14 Nov 2012 at 9:52

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

When you say "breaks whole proxy" can you describe in more detail what you see? 
 Increasing that deadline should not have broken anything, but possibly 
changing from a binary install to a source install might have.

Is there anything in the server logs?

Original comment by jmara...@google.com on 15 Nov 2012 at 1:12

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

I installed from source last night, then I couldn't  open any webpage via 
proxy. But now I tried it again to see the log, it seems work, but by testing 
500px.com, many images blank shown. It's html like:

<a title="Spider ..." href="/photo/18214069" class=""><img style="display: 
none;" 
pagespeed_high_res_src="http://pcdn.500px.net/18214069/befd832193a474a3a27320348
20080997119f8e2/x4.jpg,qt=1352980022.pagespeed.ic.sQpy154a78.jpg" 
class="disoriented" alt="4"></a>

Original comment by kri2183...@maricopa.edu on 15 Nov 2012 at 2:51

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

I don't know why the source install is not working for you.  Is your Apache 
configuration the same as before?  If you set the rewrite timeout to 10 does 
that fix your blank images problem?  

I've created Issue 571 to set the rewrite timeout with a configuration variable 
so that you don't have to edit the code and build your own binary.

Original comment by jkar...@google.com on 26 Nov 2012 at 2:17

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Apache conf same like before. Revert back to 10 fix the blank images problem 
well.

Original comment by kri2183...@maricopa.edu on 26 Nov 2012 at 6:38

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 26 Nov 2012 at 8:26

  • Changed state: Accepted
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

A few more queries to help us figure out what could be happening with your 
site: 
- With a rewrite deadline of 2000ms, were your pages loading the images 
eventually (after say 2-3 seconds) or were they just not loading them ever?
- Do you have defer_javascript enabled in addiiton to lazyload_images and 
inline_preview_images? If yes, could you try disabling defer_javascript and 
setting the rewrite timeout to the high value you used previously (2000ms?) and 
let us know if you are still seeing blank images?

Original comment by anup...@google.com on 28 Nov 2012 at 8:02

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

- With a rewrite deadline of 2000ms, were your pages loading the images 
eventually (after say 2-3 seconds) or were they just not loading them ever?

It loaded *some*, and some of them blank.

- Do you have defer_javascript enabled in addiiton to lazyload_images and 
inline_preview_images? If yes, could you try disabling defer_javascript and 
setting the rewrite timeout to the high value you used previously (2000ms?) and 
let us know if you are still seeing blank images?

I tried disable all other filters, restart server, restart browser, reset 
cache, still blank images there. 

Original comment by kri2183...@maricopa.edu on 7 Dec 2012 at 6:15

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

could kOptWaitForRewriteMsPerFlush option be configurable?
I have the same issue with images and while 2sec is way too much i think i 
could experiment with values larger than 10 to find my median time.

btw. is time spent on image optimization logged somewhere?

Original comment by l...@critical.pl on 10 Dec 2012 at 1:33

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

> btw. is time spent on image optimization logged somewhere?

I've opened a separate bug for this, as I think we need it.

http://code.google.com/p/modpagespeed/issues/detail?id=586

Original comment by jmaes...@google.com on 10 Dec 2012 at 3:52

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

I'm not sure when this went in, but we'll release-note it for 1.8.

ModPagespeedRewriteDeadlineMs xxx

is now settable in a config file.

Original comment by jmara...@google.com on 31 Jan 2014 at 4:00

  • Changed state: Fixed
  • Added labels: Milestone-v31, release-note
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmaes...@google.com on 18 Apr 2014 at 3:34

  • Changed title: Document ModPagespeedRewriteDeadlineMs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment