PageSpeed filters' cpu usage information is sorely lacking

[Jacob Share]

I'm using nginx 1.5.13 on a c1.medium EC2 instance to run WordPress and a few other, smaller, web apps. I recently spent a few days enabling SPDY and tuning the server at the same time, including installing and enabling the 1.7.30.4 ngx_pagespeed beta. I initially left the Core Filters enabled and threw in a few more, but according to Munin graphs, my CPU usage went through the roof and I had to turn off pagespeed right away. I came back to it a few weeks later when I had some time to delve into which filters were responsible, and ultimately I ended up disabling a whole bunch of image-related filters and offloaded some of their functionality to a WordPress plugin whose work is scheduled.

All this just to say that what is sorely missing from the otherwise good PageSpeed docs is a filter risk-rating with regards to CPU usage. I like that there's already a risk rating with regards to whether a filter will actually increase pageload times but without taking into the CPU usage aspect, some people are going to turn off or even rant about PageSpeed without understanding why it didn't work for them and actually slowed pageloads.

[Joshua Marantz]

The point of your email is exactly correct.  There should be a lot more examples and descriptions describing CPU time management on systems in our doc.

However I would like to point out that with image rewriting, there is typically a burst of CPU activity when PageSpeed "learns" a new site optimizing all the images

You can control the CPU usage during this burst via a few different conf file settings:

  pagespeed ImageMaxRewritesAtOnce xxx;

  pagespeed NumRewriteThreads xxx;

  pagespeed NumExpensiveRewriteThread xxx;

Once the server-side cache is warm then the CPU impact is not that large.  Even when an image's origin TTL expires, it does not need to be re-optimized unless it have actually changed.

We don't know what the exact right parameters are, and have tuned them for our desktop machines, which have 6 physical CPUs and lots of memory.  On a lowest-price AWS instance these will need to be scaled back.  It's also possible that we should do more platform analysis and try to auto-tune these settings, but there's risk in that too.

Finally I want to point out that I am skeptical that the WordPress plugin can optimize images as aggressively as PageSpeed can, because PageSpeed can optimize images in the context of the page (it knows the image dimensions) and it can optimize for the client (transcoding to webp on Chrome but not on Firefox).  We are constantly improving our image optimization stack and are chomping at the bit to get our latest updates in your hands in our next release.

But I agree with your point: we need to be more transparent about the risks and we'll put this into the image-optimization doc 'risks'.

-Josh

On Wed, Apr 9, 2014 at 10:13 AM, Jacob Share <share...@gmail.com> wrote:

I'm using nginx 1.5.13 on a c1.medium EC2 instance to run WordPress and a few other, smaller, web apps. I recently spent a few days enabling SPDY and tuning the server at the same time, including installing and enabling the 1.7.30.4 ngx_pagespeed beta. I initially left the Core Filters enabled and threw in a few more, but according to Munin graphs, my CPU usage went through the roof and I had to turn off pagespeed right away. I came back to it a few weeks later when I had some time to delve into which filters were responsible, and ultimately I ended up disabling a whole bunch of image-related filters and offloaded some of their functionality to a WordPress plugin whose work is scheduled.

All this just to say that what is sorely missing from the otherwise good PageSpeed docs is a filter risk-rating with regards to CPU usage. I like that there's already a risk rating with regards to whether a filter will actually increase pageload times but without taking into the CPU usage aspect, some people are going to turn off or even rant about PageSpeed without understanding why it didn't work for them and actually slowed pageloads.

--
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-di...@googlegroups.com.
Visit this group at http://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.