https://developers.google.com/speed/pagespeed/module/

 

구글에서 배포하는 mod_pagespeed 얼마전 저희 서버에 설치하고 잠깐 댓글로 뭔가 더 버벅이고 느려지는 느낌을 받는다고 언급한 적이 있습니다.

 

그런데 여기서 궁금한게 기존문서가 많은 사이트의 경우 이 문서들이 이미지도 변환되고 여러작입이 진행되면서 서버가 부하를 더 받는게 아닌가 생각이 들었습니다.

 

서버에서 폴더를 좀 찾아보니 이미지도 변환된 이미지가 따로 저장되어 그 이미지가 보여주어 빠르게 페이지가 열리도록 도와주는건데요. 이렇다면 모든 문서가 방문자 접속으로 인해 이 모듈에의해 변환작업이 다 이루어지고 난 이후에 부하가 좀 줄어들 것으로 생각이 듭니다.

 

제가 판단하는게 맞을까요??

 

그리고 이미지를 2개씩 서버에 가지고 있어야 하니 서버용량을 차지하는건 더 늘어난다는 것은 알고 사용해야할 자료일 듯 하구요.

 

 

  • profile

    아.. 관련 설명이 있긴 하네요. 그럼 이미지 변환이 모두 끝나고 나면 부하가 좀 덜해질거 같기도 하구요..

    https://developers.google.com/speed/pagespeed/module/filter-image-optimize#other-controls

    Optimize Images

    Risks

    Image optimization is both CPU and memory intensive. You will probably see your server load increase while images are being rewritten. This will be particularly noticeable immediately after server start. If load increases excessively, you can alleviate this problem by setting ImageMaxRewritesAtOnce and ImageResolutionLimitBytes. Once the images have been optimized, they will be cached for future use.

  • profile
    일단 다시 사용을 시작해보고 어느정도 변환이 끝날때 까지 기다려본다음 속도를 봐야겠네요.
  • profile

    마지막 줄 은 제가 착각을 한건지.... 폴더를 본듯 했는데 지금 찾으려니 못찾겠네요.

    그리고 이미지를 2개씩 서버에 가지고 있어야 하니 서버용량을 차지하는건 더 늘어난다는 것은 알고 사용해야할 자료일 듯 하구요.

     

    이미지 자체를 저장하는게 아니고 캐시형태로 저장했다가 보여주는거 같기도 하고 이건 잘 모르겠네요.

  • profile profile
    어딘가에 캐시해 둔다면 캐시에 사용할 수 있는 용량에 제한이 있을 테고, 그 용량이 가득 차면 예전에 캐시해둔 이미지를 삭제하는 게 아닌가 하는 생각이 드네요.
  • profile profile
    그렇다면 캐시한게 지워진 거라면 다시 만들때 부하가 걸리겠군요. 이럼 좀 부담스러울수 있겠습니다.

    혹시 아래에서 좀 보시고 힌트를 주실수...

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

    # 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

    # If you want mod_pagespeed process XHTML as well, please uncomment this
    # line.
    # AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER application/xhtml+xml

    # The ModPagespeedFileCachePath directory must exist and be writable
    # by the apache user (as specified by the User directive).
    ModPagespeedFileCachePath "/var/cache/mod_pagespeed/"

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

    # The locations of SSL Certificates is distribution-dependent.
    ModPagespeedSslCertDirectory "/etc/ssl/certs"


    # If you want, you can use one or more memcached servers as the store for
    # the mod_pagespeed cache.
    # ModPagespeedMemcachedServers localhost:11211

    # A portion of the cache can be kept in memory only, to reduce load on disk
    # (or memcached) from many small files.
    # ModPagespeedCreateSharedMemoryMetadataCache "/var/cache/mod_pagespeed/" 51200

    # Override the mod_pagespeed 'rewrite level'. The default level
    # "CoreFilters" uses a set of rewrite filters that are generally
    # safe for most web pages. Most sites should not need to change
    # this value and can instead fine-tune the configuration using the
    # ModPagespeedDisableFilters and ModPagespeedEnableFilters
    # directives, below. Valid values for ModPagespeedRewriteLevel are
    # PassThrough, CoreFilters and TestingCoreFilters.
    #
    # ModPagespeedRewriteLevel PassThrough

    # Explicitly disables specific filters. This is useful in
    # conjuction with ModPagespeedRewriteLevel. For instance, if one
    # of the filters in the CoreFilters needs to be disabled for a
    # site, that filter can be added to
    # ModPagespeedDisableFilters. This directive contains a
    # comma-separated list of filter names, and can be repeated.
    #
    # ModPagespeedDisableFilters rewrite_images

    # 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 rewrite_javascript,rewrite_css
    # ModPagespeedEnableFilters collapse_whitespace,elide_attributes

    # Explicitly forbids the enabling of specific filters using either query
    # parameters or request headers. This is useful, for example, when we do
    # not want the filter to run for performance or security reasons. This
    # directive contains a comma-separated list of filter names, and can be
    # repeated.
    #
    # ModPagespeedForbidFilters rewrite_images

    # How long mod_pagespeed will wait to return an optimized resource
    # (per flush window) on first request before giving up and returning the
    # original (unoptimized) resource. After this deadline is exceeded the
    # original resource is returned and the optimization is pushed to the
    # background to be completed for future requests. Increasing this value will
    # increase page latency, but might reduce load time (for instance on a
    # bandwidth-constrained link where it's worth waiting for image
    # compression to complete). If the value is less than or equal to zero
    # mod_pagespeed will wait indefinitely for the rewrite to complete before
    # returning.
    #
    # ModPagespeedRewriteDeadlinePerFlushMs 10

    # ModPagespeedDomain
    # authorizes rewriting of JS, CSS, and Image files found in this
    # domain. By default only resources with the same origin as the
    # HTML file are rewritten. For example:
    #
    # ModPagespeedDomain cdn.myhost.com
    #
    # This will allow resources found on http://cdn.myhost.com to be
    # rewritten in addition to those in the same domain as the HTML.
    #
    # Other domain-related directives (like ModPagespeedMapRewriteDomain
    # and ModPagespeedMapOriginDomain) can also authorize domains.
    #
    # Wildcards (* and ?) are allowed in the domain specification. Be
    # careful when using them as if you rewrite domains that do not
    # send you traffic, then the site receiving the traffic will not
    # know how to serve the rewritten content.

    # If you use downstream caches such as varnish or proxy_cache for caching
    # HTML, you can configure pagespeed to work with these caches correctly
    # using the following directives. Note that the values for
    # ModPagespeedDownstreamCachePurgeLocationPrefix and
    # ModPagespeedDownstreamCacheRebeaconingKey are deliberately left empty here
    # in order to force the webmaster to choose appropriate value for these.
    #
    # ModPagespeedDownstreamCachePurgeLocationPrefix
    # ModPagespeedDownstreamCachePurgeMethod PURGE
    # ModPagespeedDownstreamCacheRewrittenPercentageThreshold 95
    # ModPagespeedDownstreamCacheRebeaconingKey

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

    # 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 localhost
    Allow from 127.0.0.1
    SetHandler pagespeed_admin
    </Location>
    <Location /pagespeed_global_admin>
    Order allow,deny
    Allow from localhost
    Allow from 127.0.0.1
    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 100000
  • profile profile

    # ModPagespeedFileCacheSizeKb 102400
    # ModPagespeedFileCacheCleanIntervalMs 3600000

    이 부분이 의심스럽네요. 주석을 해제하지 않으면 기본값 그대로 적용되거든요. 용량 제한 100MB, 그리고 용량이 남아 있더라도 1시간(3600000밀리초)마다 캐시를 비우는 것이 기본값인 듯 합니다.

  • profile profile
    힌트 감사합니다. 이 옵션을 크게 늘려 계속 사용할건지 아니면 이미지 컨버팅은 빼야 할지 고민해봐야겠습니다. 이미지컨버팅에 리소스가 많이 필요하네요.
  • ?
    국내에서 거의 사용되지 않는걸 보니 그닥 효과는 없는 모듈인듯하네요
  • ? profile
    아닐걸요. 사용법을 모르고 웹호스팅에는 사용이 어렵기 때문이죠. 나름 효과가 클거 같습니다.
  • ?

    이미지를 webp형태로 변환해주는게 매력적이긴 한데, 그거 외에서는 그렇게 눈에 띌만한 효과를 보기는 어렵겠네요. 그래도 최근 웹사이트에서는 이미지 파일을 최적화 시키는게 관건인 커뮤니티형 사이트들이 상당히 많기 때문에, 그걸 노리고 적용하는건 충분히 고려해볼만한것 같아요.

    엥? 그러고 보면 효과가 충분히 좋은거 아닌가 싶기도 하고.. xe는 썸네일 최적화는 안해주잖아요? 이거랑 결합되면 더 좋아질수도.

  • ? profile
    근데 한가지 궁금한게 생겼네요. 페이지를 한번 읽게 되면 이 모듈이 이미지를 변환해 줘서 webp 형태의 이미지로 보여줍니다. 그런데 이게 캐시 지속시간이 있는지 한참후에 다시 페이지를 열면 jpg와 같은 원래 포맷으로 보이네요. 그리고 다시 페이지를 읽어보면 webp로 보이구요.

    이게 다시 webp로 보여지기 위해 또 변환을 하는건지 아니면 이미 변환된것을 다시 보여주는건지 이게 관건인듯 합니다. 일정시간 이후 다시 변환해야 한다면 cpu와 메모리에 부담이 클거 같아서요. 지금은 가동 초기라 다 변환되길 기대하고 있는데 이게 잘못생각한거라면 낭패지요.
  • profile ?
    원래의 jpg포맷으로 보인다는게 무엇을 의미하는지 모르겠습니다. 만약 실제로 그렇다면 캐시 시간의 문제라기 보다는 뭔가 다른쪽이 아닐까요? pagespeed를 적용하면 내부 이미지는 전부 webp로 변환되어서 보여야되는건데..

    만약 클라우드 플레어같은 cdn을 이용했을때의 그쪽의 이미지 최적화나 동기화같은 그런 부분도 고려대상이 아닐까요?
  • ? profile
    현재 클라우드 플레어와 같은 CDN은 사용하지 않고있고요.
    어떤이야기냐면.... 페이지를 읽음과 동시에 이미지가 변환이 됩니다. webp 포맷으로요. 그래서 읽은 페이지를 다시 읽어보면 그때서 webp 포맷으로 읽어온게 보입니다.(제가 테스트한건 새탭에서 이미지 열기로 파일명확인...)

    그런데 이후 한참 후에 다시 그 페이지를 열어서 새탭으로 이미지를 열어 보면 jpg로 확인됩니다. 그 이후 다시 페이지를 접근해서 새탭으로 이미지를 열어보면 다시 webp 포맷으로 되어 있다는 거죠.

    그런데 이게 최조에만 변환을위해 CPU와 메모리 리소스를 사용하고 이후 다시 webp로 보여줄때는 이미 변환된 것을 보여주는 작업이라면 그래도 부담이 덜 됩니다.

    그러데 제가 궁금한건 왜 일정 시간 지나서 다시 페이지에 접속해 보면 webp 포맷이 아니냐는 거죠.
  • profile
    으엌.. 스크롤이...

    혹시 사이트에 AJAX 관련된 부분이 동작하거나 하나요?
    비슷한 상황을 재현한듯한데.. 제 경우엔 차이점이 AJAX인거 같아서요.

    webp(1)에서 jpg(2)로 보였다가 다시 webp(3)로 바뀌는 경우에도
    원본파일뒤에 붙는 문자열이 동일한거 보면(랜덤으로 붙는거라면 재변환했을때 바뀔꺼라고 추측..)
    단순히 mod_pagespeed가 게시글을 뿌려줄때 작동에 뭔가 간섭을 받은게 아닌가싶어요.
  • profile profile
    위에 @기진곰님의 답변이 정확한 듯 합니다. 결국은 이미지 변환만 필터링해서 나머지 기능은 사용하기로 했습니다.
    지금 기본제한으로 파일8개를 처리하게 되어있는데도 부담을 많이 주네요. 저희 서버가 클라우드서버이고 메모리하고 CPU가 작다보니 부담이 됩니다.

    나머지 기능은 아주 훌륭합니다. mod_pagespeed 에서 지원하는 Lazyload를 방금 활성화 했습니다.

    기진곰님 답변대로 1시간 혹은 100M에서 캐시를 비우는게 정확한거 같아요. 이렇게 되면 어찌되었던 비우고 다시 시작하는 상황이 반복되기 때문에 하드웨어사양이 아주 좋다면 이미지컨버팅도 쓰면 괜찮은데 저희 상황으로서는 이미지컨버팅은 빼고 나머지 기능을 최대한 활용하면 도움이 많이 될 것 같은 결론에 도달하게 되네요.
  • profile
    기진곰님 댓글보고 캐시폴더를 지우고 확인해보니까
    여기서도 웹지기님이 얘기하신 현상이 재현되네요.
    Ajax쪽은 mod_speedpage가 잘 건드리질 못하는 느낌이고..

    결국 제가 추구하던 '이미지 용량줄이기'는 mod_speedpage도 반쪽짜리...
  • ?
    그렇다면 저 캐시 사이즈랑 시간을 쭉 늘려서 사용한다면 기존에 목표하셨던 방식대로 사용하는게 아닐까요?
  • ? profile
    캐시사이즈는 그렇다 하더라도 캐시 시간을 무한대로 주지 않으면 또 컨버팅해야 하기에 그냥 이미지컨버팅만 빼기로 했습니다. 나머지 기능도 많고 도움이 되는게 많습니다.
  • profile ?

    그런데 제가 문서를 읽어보니, 캐시 시간은 그저 체크 시간일뿐 정확히는 캐시 사이즈에만 영향을 받습니다. 해당 캐시 기준시간동안 사이즈가 가득 찻을때만, 75%까지 비워냅니다. 아래 참고해보세요. 아래 글에서 말하는건 해당 시간이 흘러갔을때 만약 캐시 사이즈나 inode 제한이 생겼을 경우에만 75%아래로 만든다고 되어 있습니다.

     

    그리고 이 캐시는 LRU에 영향을 받기 때문에, 가장 오랫동안 사용되지 않았던 캐시를 우선순위로 비워주게 되어 있습니다. 정말 효율적인 시스템이네요 ㅋㅋ

     

    아래의 룰에 따르면 결론은 충분히 캐시 사이즈만 늘려서 사용 가능한 수준으로 보여지네요.

     

    It is important to note that FileCacheSizeKb and FileCacheInodeLimit do not define absolute limits on the cache size and inode count. The cache cleaning process will run at the time interval defined by FileCacheCleanIntervalMs, and will only initiate cleaning if the cache size exceedsFileCacheSizeKb or the cache inode count exceeds FileCacheInodeLimit. When cache cleaning is initiated, the oldest files in the cache will be removed until the cache size is under 0.75 * FileCacheSizeKb and the inode count is under 0.75 * FileCacheInodeLimit.