Good article. Personally, I'm not sure I'd agree with the trade off regarding using PageSpeed.
If I'm reading your graphs right, once you hit around 60 requests per second, performance starts degrading rapidly, to the extent where you are generating errors and can't serve content at all.
Without PageSpeed, you're essentially serving up to 350+ requests per second with absolutely no errors/timeouts, and only a slight degradation in response times.
You mention it's a compromise, but the central question is do you want a site that has content that can load quickly, but can collapse and not serve any content at all, or a site that may be slightly slower loading on a device, but continually stays up serving content in a reasonable time frame?
Anyway, thanks for the insights, some good stuff there.
It's worth noting that the test is really only to show how much extra resources pagespeed requires. The timeout was set to only 1sec, so in the real world it would go well beyond 60req/sec as timeouts would be much more like 10secs.
Also when loading real pages and not just hitting the server other factors like requesting static assets etc would come into play in favour of pagespeed.
One quick note: Nginx does not serve any of its caches out of memory, it's served from disk. This is a difference without distinction when you have lots of memory, since Nginx will end up sendfile-ing the file from the disk cache, but it's worth noting.
On a machine with enough memory, this is an unnecessary optimization. In most use cases, Nginx will be serving a number of static assets from disk in addition to the cached files, and allowing for more memory to be used on the OS' disk cache will make the entire site more responsive.
If I'm reading your graphs right, once you hit around 60 requests per second, performance starts degrading rapidly, to the extent where you are generating errors and can't serve content at all.
Without PageSpeed, you're essentially serving up to 350+ requests per second with absolutely no errors/timeouts, and only a slight degradation in response times.
You mention it's a compromise, but the central question is do you want a site that has content that can load quickly, but can collapse and not serve any content at all, or a site that may be slightly slower loading on a device, but continually stays up serving content in a reasonable time frame?
Anyway, thanks for the insights, some good stuff there.