Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
[deleted comment]
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
Original comment by jmara...@google.com
on 26 Nov 2012 at 8:26
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
- 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
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
> 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
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
Original comment by jmaes...@google.com
on 18 Apr 2014 at 3:34
Original issue reported on code.google.com by
kri2183...@maricopa.edu
on 14 Nov 2012 at 7:26