search

apache / incubator-pagespeed-mod

Apache module for rewriting web pages to reduce latency and bandwidth.
http://modpagespeed.com
Apache License 2.0
696 stars 158 forks source link

Pagespeed increases Time To First Byte #1293

Open Algram opened 8 years ago

Algram commented 8 years ago

Hello, we installed the latest pagespeed module on our servers (1.9.32.14-stable). There are noticable improvements and the module obviously does its job.

The only problem is that in total the page does not load faster, since the Time To First Byte (TTFB) gets doubled (in some cases tripled). We thought pagespeed put too much load on our servers and therefore it slowed down, but we can barely notive any load at all. There has to be another bottleneck.

Has anyone else experienced this issue? Thanks for you help!

morlovich commented 8 years ago

This is quite surprising, since we try really hard not to delay anything. What kinds of resources did you see the TTFB change in?

On Fri, Apr 22, 2016 at 4:10 AM, Algram notifications@github.com wrote:

Hello, we installed the latest pagespeed module on our servers (1.9.32.14-stable). There are noticable improvements and the module obviously does its job.

The only problem is that in total the page does not load faster, since the Time To First Byte (TTFB) gets doubled (in some cases tripled). We thought pagespeed put too much load on our servers and therefore it slowed down, but we can barely notive any load at all. There has to be another bottleneck.

Has anyone else experienced this issue? Thanks for you help!

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/pagespeed/mod_pagespeed/issues/1293

Algram commented 8 years ago

It happens on the very first request made.

morlovich commented 8 years ago

On Fri, Apr 22, 2016 at 9:24 AM, Algram notifications@github.com wrote:

It happens on the very first request made.

Do you mean the HTML, or first request of any kind?

Algram commented 8 years ago

Yeah I am talking about the HTML there. Like the "main" request so to say.

morlovich commented 8 years ago

Hmm, so only have vague guesses:

  1. Is this a fresh install, or an upgrade from a previous version showing a regression?
  2. So the reason I asked about "any kind" is that one thing I've seen is if I try to load-test stuff Apache runs out of processes, and then it can take it as much as half a second to spawn new ones --- and we can make this more likely to happen (as if you have foo.html, using bar.png and bar.jpeg, we will end up fetching bar.png and bar.jpeg from Apache, potentially keeping some processes busy). If that happens, there should be a note from the server in your error_log, telling of what knobs to tweak. That would also happen only occasionally, and it sounds like it's basically all the time?
  3. Might be worth to peek at the log in general, if you haven't already. Sometimes it may hint as stuff like a permissions problem in the cache directory or something like that that can cause performance trouble.
  4. One time I can think of we can see this sort of problem is if your HTML files are really huge (megabytes?) and delivered to us in one gulp. Is that the case?
  5. How different is your configuration from the example one?
oschaaf commented 8 years ago

Cross linking similar report on mps-discuss: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mod-pagespeed-discuss/cLE9qIYb_rg/KZceqhuwAgAJ

Algram commented 8 years ago

@morlovich Thanks for your help, I'll answer your questions as far as I can:

I'll get back to you on 1.

jmarantz commented 8 years ago

A few more questions:

  1. Can you share your URL?
  2. Do you still have TTFB problems when viewing your page with query-param ?PageSpeed=off ?
  3. Can you add ?PageSpeedFilters=+debug and look at the resulting HTML output? This debug feature inject HTML comments telling us how many milliseconds were spent parsing, waiting for HTML, rendering/optimizing, etc.
  4. Without PageSpeed, are you caching HTML in a caching proxy like Varnish?
Algram commented 8 years ago

@jmarantz

  1. I can share the URL privately if you want.
  2. The TTFB options still appear with the query-param that disable PageSpeed
  3. Here is the result I get with the debug option. It seems there is a fair bit of idle-time, but only about 90ms which does not explain the 500ms increase in our TTFB
#Flush after     82647us
#Parse duration  55939us
#Render duration 573108us
#Idle duration   26708us
-->
<!--
#Flush after     717760us
#Parse duration  0us
#Render duration 10639us
#Idle duration   62005us
--><!--
mod_pagespeed on
Filters:
ah  Add Head
gp  Convert Gif to Png
jp  Convert Jpeg to Progressive
jw  Convert Jpeg To Webp
mc  Convert Meta Tags
pj  Convert Png to Jpeg
db  Debug
ec  Cache Extend Css
ei  Cache Extend Images
es  Cache Extend Scripts
hw  Flushes html
ii  Inline Images
id  Insert Image Dimensions
js  Jpeg Subsampling
rj  Recompress Jpeg
rp  Recompress Png
rw  Recompress Webp
ri  Resize Images
cp  Strip Image Color Profiles
md  Strip Image Meta Data

Options:
EnableCachePurge (euci) True
EnableRewriting (e) 1
ImageInlineMaxBytes (ii) 50000
RewriteLevel (l) Pass Through
RunExperiment (fur) False
StatisticsLogging (asle) True

#NumFlushes            1
#EndDocument after     717760us
#Total Parse duration  55939us
#Total Render duration 583747us
#Total Idle duration   88713us

I do not exactly know if we have a caching proxy inbetween. I can get that information if you really need it though.

jmarantz commented 8 years ago

Those timing numbers look higher than I expect by a factor of 10.

Is this a binary install or your own build?

What hardware is it running on? How many cores? Processor, clock rate, memory?

Where is your cache? A local hard disk? Memcached? How large? Could you paste your pagespeed config?

How is Apache configured? Which version? Which mpm?

Also did you say you get the same TTFB with pagespeed off in the query params?

Algram commented 8 years ago

@jmarantz

oschaaf commented 8 years ago

@Algram If you could share the url privately that would be helpful

mbunzel commented 8 years ago

This is quite surprising, since we try really hard not to delay anything.

May I ask what degree of TTFB delay you'd expect to see? We've recently started using pagespeed 1.11.33.0 on nginx 1.9.15 and noticed a TTFB increase from 70ms (?PageSpeed=off) to 200ms on a warm cache. Config and numbers (plus some experiments; why does inline_images cause it to flush way earlier?) can be found here.

We've thought of this as a reasonable trade-off for the features pagespeed provides, but your comment makes it sound as though the additional ~130ms to first byte is higher than expected.

Algram commented 8 years ago

@oschaaf If you give me an email I can send it to you.

oschaaf commented 8 years ago

@Algram oschaaf at we-amp.com

oschaaf commented 8 years ago

@Algram I received the url, thanks. One thing I noticed is that the server uses a chunked transfer encoding even when I request the html without gzip compression. Do you know if the script that generates the html induces one or more flushes?

jmarantz commented 8 years ago

@mbunzel inlining images does not induce extra flushes. But setting that limit to 50000 (see https://github.com/pagespeed/mod_pagespeed/issues/1293#issuecomment-214728802) is probably not helping performance overall.

I'd expect ~10ms overhead for mod_pagespeed's HTML parser on typical HTML on a typical machine. But expect that to be higher on a slow machine or a huge HTML file. Image inlining won't affect that because we don't reparse our own output.

Then I'd expect (with default settings) up to another 10ms overhead per FLUSH. This is because at every FLUSH, we will wait up to 10ms for background optimizations to complete before giving up and serving them unoptimized. Once the cache is warm, that should become negligible.

HOWEVER...we do wait arbitrarily long for metadata cache lookups to complete. So if the caching infrastructure is really slow (e.g. file-cache on a networked file system), things can get pretty bad. Having a sufficiently large shared-memory metadata cache can really help though.

See my old blog post to learn what the metadata cache is: http://modpagespeed.jmarantz.com/2012/12/caching-in-modpagespeed.html

So, an increase from 70ms to 200ms is a higher penalty than I expect, and it is probably worth looking at the caching setup and you default settings to tweak the tuning.

Algram commented 8 years ago

@oschaaf That is quite possible. Why would that have such a huge hit on performance though? I mean we are talking about 500ms in some cases.

mbunzel commented 8 years ago

@jmarantz I think you confused me with @Algram, my cache lookups are fast and I didn't increase ImageInlineMaxBytes. This issue just made me realize that the increased TTFB I'm seeing might not be considered normal behavior for pagespeed (I thought it was a trade-off) and your description of how flushing is supposed to work pretty much confirms it. Turns out I'm most likely hitting a known bug in ngx_pagespeed.

Algram commented 8 years ago

@oschaaf It seems that we are not flushing manually.

@jmarantz you asked for our pagespeed config earlier, here it is:

# Attempt to load mod_version if it wasn't loaded or compiled in (eg on Debian)
<IfModule !mod_version.c>
  LoadModule version_module /app/live/apache2/modules/mod_version.so
</IfModule>

<IfVersion < 2.4>
  LoadModule pagespeed_module /app/live/apache2/modules/mod_pagespeed.so
</IfVersion>
<IfVersion >= 2.4.2>
  LoadModule pagespeed_module /app/live/apache2/modules/mod_pagespeed_ap24.so
</IfVersion>

# Only attempt to load mod_deflate if it hasn't been loaded already.
<IfModule !mod_deflate.c>
 LoadModule deflate_module /app/live/apache2/modules/mod_deflate.so
</IfModule>
<IfModule pagespeed_module>

    # The ModPagespeedFileCachePath directory must exist and be writable
    # by the apache user (as specified by the User directive).
    ModPagespeedFileCachePath            "/home/ecom/pagespeed/cache"
    ModPagespeedFileCacheSizeKb          256000

    # LogDir is needed to store various logs, including the statistics log
    # required for the console.
    ModPagespeedLogDir "/home/ecom/pagespeed/log"

    # Turn on mod_pagespeed. To completely disable mod_pagespeed, you
    # can set this to "off".
    ModPagespeed off

    # We want VHosts to inherit global configuration.
    # If this is not included, they'll be independent (except for inherently
    # global options), at least for backwards compatibility.
    ModPagespeedInheritVHostConfig on

    # Direct Apache to send all HTML output to the mod_pagespeed
    # output handler.
    AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html

    ModPagespeedRewriteLevel PassThrough

    #Add Owl-Framework LazyLoading Images
    #
    ModPagespeedUrlValuedAttribute img data-src image    

    # Explicitly enables specific filters. This is useful in
    # conjuction with ModPagespeedRewriteLevel. For instance, filters
    # not included in the CoreFilters may be enabled using this
    # directive. This directive contains a comma-separated list of
    # filter names, and can be repeated.
    #

    ModPagespeedEnableFilters extend_cache
    ModPagespeedEnableFilters rewrite_images,insert_image_dimensions
    ModPagespeedEnableFilters add_head,convert_meta_tags

    # Filter-Parameters
    #
    #ModPagespeedForceCaching on
    ModPagespeedBeaconUrl "/static/dist/external/pagespeed/"
    ModPagespeedStaticAssetPrefix "/static/dist/external/pagespeed/"
    ModPagespeedEnableCachePurge on
    ModPagespeedImageInlineMaxBytes 5000

    # Limit the number of inodes in the file cache. Set to 0 for no limit.
    # The default value if this paramater is not specified is 0 (no limit).
    #ModPagespeedFileCacheInodeLimit        500000

    # Bound the number of images that can be rewritten at any one time; this
    # avoids overloading the CPU.  Set this to 0 to remove the bound.
    #
    # ModPagespeedImageMaxRewritesAtOnce      8

    # You can also customize the number of threads per Apache process
    # mod_pagespeed will use to do resource optimization. Plain
    # "rewrite threads" are used to do short, latency-sensitive work,
    # while "expensive rewrite threads" are used for actual optimization
    # work that's more computationally expensive. If you live these unset,
    # or use values <= 0 the defaults will be used, which is 1 for both
    # values when using non-threaded MPMs (e.g. prefork) and 4 for both
    # on threaded MPMs (e.g. worker and event). These settings can only
    # be changed globally, and not per virtual host.
    #
    # ModPagespeedNumRewriteThreads 4
    # ModPagespeedNumExpensiveRewriteThreads 4

    # Randomly drop rewrites (*) to increase the chance of optimizing
    # frequently fetched resources and decrease the chance of optimizing
    # infrequently fetched resources. This can reduce CPU load. The default
    # value of this parameter is 0 (no drops).  90 means that a resourced
    # fetched once has a 10% probability of being optimized while a resource
    # that is fetched 50 times has a 99.65% probability of being optimized.
    #
    # (*) Currently only CSS files and images are randomly dropped.  Images
    # within CSS files are not randomly dropped.
    #
    # ModPagespeedRewriteRandomDropPercentage 90

    # Many filters modify the URLs of resources in HTML files. This is typically
    # harmless but pages whose Javascript expects to read or modify the original
    # URLs may break. The following parameters prevent filters from modifying
    # URLs of their respective types.
    #
    # ModPagespeedJsPreserveURLs on
    # ModPagespeedImagePreserveURLs on
    # ModPagespeedCssPreserveURLs on

    # When PreserveURLs is on, it is still possible to enable browser-specific
    # optimizations (for example, webp images can be served to browsers that
    # will accept them).  They'll be served with Vary: Accept or Vary:
    # User-Agent headers as appropriate.  Note that this may require configuring
    # reverse proxy caches such as varnish to handle these headers properly.
    #
    # ModPagespeedFilters in_place_optimize_for_browser

    # Internet Explorer has difficulty caching resources with Vary: headers.
    # They will either be uncached (older IE) or require revalidation.  See:
    # http://blogs.msdn.com/b/ieinternals/archive/2009/06/17/vary-header-prevents-caching-in-ie.aspx
    # As a result we serve them as Cache-Control: private instead by default.
    # If you are using a reverse proxy or CDN configured to cache content with
    # the Vary: Accept header you should turn this setting off.
    #
    # ModPagespeedPrivateNotVaryForIE on

    # Settings for image optimization:
    #
    # Lossy image recompression quality (0 to 100, -1 just strips metadata):
    # ModPagespeedImageRecompressionQuality 85
    #
    # Jpeg recompression quality (0 to 100, -1 uses ImageRecompressionQuality):
    # ModPagespeedJpegRecompressionQuality -1
    # ModPagespeedJpegRecompressionQualityForSmallScreens 70
    #
    # WebP recompression quality (0 to 100, -1 uses ImageRecompressionQuality):
    # ModPagespeedWebpRecompressionQuality 80
    # ModPagespeedWebpRecompressionQualityForSmallScreens 70
    #
    # Timeout for conversions to WebP format, in
    # milliseconds. Negative values mean no timeout is applied. The
    # default value is -1:
    # ModPagespeedWebpTimeoutMs 5000
    #
    # Percent of original image size below which optimized images are retained:
    # ModPagespeedImageLimitOptimizedPercent 100
    #
    # Percent of original image area below which image resizing will be
    # attempted:
    # ModPagespeedImageLimitResizeAreaPercent 100

    # Settings for inline preview images
    #
    # Setting this to n restricts preview images to the first n images found on
    # the page.  The default of -1 means preview images can appear anywhere on
    # the page (if those images appear above the fold).
    # ModPagespeedMaxInlinedPreviewImagesIndex -1

    # Sets the minimum size in bytes of any image for which a low quality image
    # is generated.
    # ModPagespeedMinImageSizeLowResolutionBytes 3072

    # The maximum URL size is generally limited to about 2k characters
    # due to IE: See http://support.microsoft.com/kb/208427/EN-US.
    # Apache servers by default impose a further limitation of about
    # 250 characters per URL segment (text between slashes).
    # mod_pagespeed circumvents this limitation, but if you employ
    # proxy servers in your path you may need to re-impose it by
    # overriding the setting here.  The default setting is 1024
    # characters.
    #
    # ModPagespeedMaxSegmentLength 250

    # Uncomment this if you want to prevent mod_pagespeed from combining files
    # (e.g. CSS files) across paths
    #
    # ModPagespeedCombineAcrossPaths off

    # Renaming JavaScript URLs can sometimes break them.  With this
    # option enabled, mod_pagespeed uses a simple heuristic to decide
    # not to rename JavaScript that it thinks is introspective.
    #
    # You can uncomment this to let mod_pagespeed rename all JS files.
    #
    # ModPagespeedAvoidRenamingIntrospectiveJavascript off

    # Certain common JavaScript libraries are available from Google, which acts
    # as a CDN and allows you to benefit from browser caching if a new visitor
    # to your site previously visited another site that makes use of the same
    # libraries as you do.  Enable the following filter to turn on this feature.
    #
    # ModPagespeedEnableFilters canonicalize_javascript_libraries

    # The following line configures a library that is recognized by
    # canonicalize_javascript_libraries.  This will have no effect unless you
    # enable this filter (generally by uncommenting the last line in the
    # previous stanza).  The format is:
    #    ModPagespeedLibrary bytes md5 canonical_url
    # Where bytes and md5 are with respect to the *minified* JS; use
    # js_minify --print_size_and_hash to obtain this data.
    # Note that we can register multiple hashes for the same canonical url;
    # we do this if there are versions available that have already been minified
    # with more sophisticated tools.
    #
    # Additional library configuration can be found in
    # pagespeed_libraries.conf included in the distribution.  You should add
    # new entries here, though, so that file can be automatically upgraded.
    # ModPagespeedLibrary 43 1o978_K0_LNE5_ystNklf http://www.modpagespeed.com/rewrite_javascript.js

    # Explicitly tell mod_pagespeed to load some resources from disk.
    # This will speed up load time and update frequency.
    #
    # This should only be used for static resources which do not need
    # specific headers set or other processing by Apache.
    #
    # Both URL and filesystem path should specify directories and
    # filesystem path must be absolute (for now).
    #
    # ModPagespeedLoadFromFile "http://example.com/static/" "/var/www/static/"

    # Enables server-side instrumentation and statistics.  If this rewriter is
    # enabled, then each rewritten HTML page will have instrumentation javacript
    # added that sends latency beacons to /mod_pagespeed_beacon.  These
    # statistics can be accessed at /mod_pagespeed_statistics.  You must also
    # enable the mod_pagespeed_statistics and mod_pagespeed_beacon handlers
    # below.
    #
    # ModPagespeedEnableFilters add_instrumentation

    # The add_instrumentation filter sends a beacon after the page onload
    # handler is called. The user might navigate to a new URL before this. If
    # you enable the following directive, the beacon is sent as part of an
    # onbeforeunload handler, for pages where navigation happens before the
    # onload event.
    #
    # ModPagespeedReportUnloadTime on

    # Uncomment the following line so that ModPagespeed will not cache or
    # rewrite resources with Vary: in the header, e.g. Vary: User-Agent.
    # Note that ModPagespeed always respects Vary: headers on html content.
    # ModPagespeedRespectVary on

    # Uncomment the following line if you want to disable statistics entirely.
    #
    # ModPagespeedStatistics off

    # These handlers are central entry-points into the admin pages.
    # By default, pagespeed_admin and pagespeed_global_admin present
    # the same data, and differ only when
    # ModPagespeedUsePerVHostStatistics is enabled.  In that case,
    # /pagespeed_global_admin sees aggregated data across all vhosts,
    # and the /pagespeed_admin sees data only for a particular vhost.
    #
    # You may insert other "Allow from" lines to add hosts you want to
    # allow to look at generated statistics.  Another possibility is
    # to comment out the "Order" and "Allow" options from the config
    # file, to allow any client that can reach your server to access
    # and change server state, such as statistics, caches, and
    # messages.  This might be appropriate in an experimental setup.
    <Location /pagespeed_admin>
        Order allow,deny
        Allow from all
        # Allow from 0.0.0.0
        SetHandler pagespeed_admin
    </Location>
    <Location /pagespeed_global_admin>
        Order allow,deny
        Allow from all
        # Allow from 0.0.0.0
        SetHandler pagespeed_global_admin
    </Location>

    # Enable logging of mod_pagespeed statistics, needed for the console.
    ModPagespeedStatisticsLogging on

    # Page /mod_pagespeed_message lets you view the latest messages from
    # mod_pagespeed, regardless of log-level in your httpd.conf
    # ModPagespeedMessageBufferSize is the maximum number of bytes you would
    # like to dump to your /mod_pagespeed_message page at one time,
    # its default value is 100k bytes.
    # Set it to 0 if you want to disable this feature.
    #ModPagespeedMessageBufferSize 1000
</IfModule>
jmarantz commented 8 years ago

Is /home/ecom/pagespeed/cache on a local hard disk, or a network mount?

Is 256MB cache enough to hold all the content on your site? Note that images may be stored in the cache multiple times, as they can be optimized differently depending on the browser.

Algram commented 8 years ago

@jmarantz The mentioned folder lies in our RAM. We checked several times and the cache is sufficient enough right now. At this point it is not on by default but we are only turning it on with URL params.

patricebrun commented 8 years ago

Hello, I have the same problem :

Do you have a solution ?

jmarantz commented 8 years ago

It's possible this issue might be resolved by https://github.com/pagespeed/ngx_pagespeed/commit/ebe7c61f4ffb3f1c7deb47b348d59f0aad3e9338

this lets the system start emitting the first byte of HTML prior to receiving the last byte of HTML.

patricebrun commented 8 years ago

thank you @jmarantz for your reply but I think patch concerns ngnx then I use apache

jmarantz commented 8 years ago

Sorry about that! I do have some comments that apply generally, then, on what to expect, because PageSpeed does HTML transformations and there is some TTFB impact.

Before we go into any of that, can you give more data points? E.g. can you do 9 tests using webpagetest and look at the scatter-plot "plot full results" in the WPT UI for TTFB? That will give us a much better picture than a single data-point, and will also iron out any server-side cache warming issues. Once you've done that:

  1. Count on a few milliseconds, maybe up to say 20ms for parsing the HTML. This of course varies on how long your HTML is, and how fast the machine is that's running mod_pagespeed.
  2. If you are rewriting resources (e.g. CoreFilters, which is the default), then every resource encountered in the HTML markup requires that PageSpeed do a lookup to its own server-side cache, to determine what the rewritten resource URL is. If there is a cache miss, then PageSpeed will try to optimize the resource on the spot, and will give it a deadline of 10ms by default. But in the case of a cache hit, we do not impose a deadline. If your cache is slow, the TTFB will be impacted.

There are two potential remedies for this:

  1. Configure your cache so it's fast
  2. try to flush out your HTML more often. A good place to do that might be after </head>. The way you induce your flush will differ depending on how your HTML is generated. E.g. there is a "$flush" command or similar in PHP (or so I'm told) and PageSpeed will respect that.

Let me describe in more detail how to configure your cache so it's fast:

  1. Make sure your L1 cache (lru-cache or shared-memory cache) is appropriately sized. An appropriate size depends of course on your server's HW capabilities, as well size of your site overall.
  2. Make sure your L2 cache is reasonable. If it's a file-cache it should absolutely be on a local hard disk. If you try and use a network mounted file-system for the PageSpeed file-cache you will get TTFB problems. You can also use memcached if you want to share your cache across multiple servers. Try to make sure the machines running memcached are a short network-distance from your machines running mod_pagespeed. Ideally you should have ping times of a couple of milliseconds.

Hope this helps! -Josh

patricebrun commented 8 years ago

Thank you @jmarantz for your advice , is the result of wpt , do you see anything unusual ?

jmarantz commented 8 years ago

Your WPT run looks like it just had one iteration. These TTFB latency numbers can vary widely based on a number of things, so I'd really like to see a repeat-count of 9.

I also refreshed your site a few times and then looked at view->source with ?PageSpeedFilters=+debug

That inserts some timing info as HTML comments at the end of the file:

NumFlushes 0

EndDocument after 16049us

Total Parse duration 7483us

Total Render duration 104111us

Total Idle duration 8566us

So it looks like it takes about 7.5ms for pure HTML parsing, but 104ms are consumed rendering your document, which is likely the time that it takes to do all the cache lookups. That's too long. Can you describe the hardware and cache setup you are using?

patricebrun commented 8 years ago

My configuration is as follows :

My cache is local (on hard drive)

jmarantz commented 8 years ago

Thanks for the HW config. Seems reasonable. What does your PageSpeed cache configuration look like? How big is your site (e.g. if it's static, cd to its root and type "du -h -s")?

Do you have a setting for the rewrite deadline (https://developers.google.com/speed/pagespeed/module/system#rewrite_deadline) or did you leave the default?

You could also look at /pagespeed_admin/statistics and see what your cache hit-rate looks like.

patricebrun commented 8 years ago
jmarantz commented 8 years ago

Sorry -- this fell off my radar. The cache-hit count by itself is not interesting; it's a numerator. I need to get it and the cache-miss rater otherwise I can't construct a denominator :)

Can you give me more details on the cache configuration? E.g. what are all the lines with 'Cache' in them in pagespeed.conf?

When you say "21GO" are you saying that the directory structure containing your entire site is 21 gigabytes?

patricebrun commented 8 years ago

Hello @jmarantz , Here are my cache configuration

ModPagespeedDownstreamCachePurgeLocationPrefix

    # ModPagespeedDownstreamCachePurgeMethod PURGE     # 95 ModPagespeedDownstreamCacheRewrittenPercentageThreshold     # ModPagespeedDownstreamCacheRebeaconingKey

    # Other defaults (cache sizes and Thresholds)     #     ModPagespeedFileCacheSizeKb 10096000     # 3600000 ModPagespeedFileCacheCleanIntervalMs     # ModPagespeedLRUCacheKbPerProcess 1024     ModPagespeedLRUCacheByteLimit # 16384     ModPagespeedCssFlattenMaxBytes # 102400     # ModPagespeedCssInlineMaxBytes 2048     ModPagespeedCssImageInlineMaxBytes 0 #     # ModPagespeedImageInlineMaxBytes 3072     # ModPagespeedJsInlineMaxBytes 2048     # ModPagespeedCssOutlineMinBytes 3000     # ModPagespeedJsOutlineMinBytes 3000     # -1 ModPagespeedMaxCombinedCssBytes     ModPagespeedMaxCombinedJsBytes 1800000

    # Limit the number of inodes in the file cache. Set to 0 for no limit.     # The default value if this paramater is not specified is 0 (no limit).     ModPagespeedFileCacheInodeLimit 500000

    # Bound the number of pictures That can be rewritten at Any one time; this     # Avoids overloading the CPU. Set this to 0 to remove the bound.     #     ModPagespeedImageMaxRewritesAtOnce 16

    Vous pouvez aussi # customize the number of threads per process Apache     # Mod_pagespeed will use to do resource optimization. Plain     # "Rewrite threads" are used to do short, latency-sensitive work,     # While "expensive rewrite threads" are used for actual optimization     # Work that's more computationally expensive. If you live thesis unset,     # Or use values ​​<= 0 the defaults will be used, qui est 1 for Both     # Values ​​When using non-threaded MPMs (prefork e.g.) and 4 for Both     # Is threaded MPMs (e.g. worker and events). These settings can only     # Be changed globally, and not per virtual host.     #     # 4 ModPagespeedNumRewriteThreads     # 4 ModPagespeedNumExpensiveRewriteThreads

The result of the -s -h is: 21G

jmarantz commented 8 years ago

So it looks like your file-cache is 10G and your site size is 21G. Of course MPS will not cache your HTML, but it may cache several versions of your images depending on the browser capabilities & connection.

I am thinking it wouldn't hurt to bump up your cache size to 100G (add another zero) to your ModPagespeedFileCacheSizeKb config.

You also might want to increase the size of your shared-memory metadata cache.

https://developers.google.com/speed/pagespeed/module/system#shm_cache

How big you need to make the SHM cache depends on the shared-memory cache-hit rate, which is (from /pagespeed_admin/statistics) shm_cache_hits / (shm_cache_hits + shm_cache_misses)

Increasing the size of your shm-cache until your cache hit rate plateaus will probably help your time-to-first-byte.

-Josh

On Tue, Aug 9, 2016 at 2:58 AM, patricebrun notifications@github.com wrote:

ModPagespeedFileCacheSizeKb 10096000

The result of the -s -h is: 21G

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pagespeed/mod_pagespeed/issues/1293#issuecomment-238469904, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2kPWJch5SjkQxiBi1tduCiCc2U2rdTks5qeCUYgaJpZM4INZJS .