Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Caching options are also available for the User Interface's "server-side rendering" (which uses Angular Universal).  Server-side rendering is used to pre-generate full HTML pages and pass those back to users.  This is necessary for Search Engine Optimization (SEO) as some web crawlers cannot use Javascript.  It also can be used to immediately show the first page more "quickly" HTML page to users while the Javascript app loads in the user's browser.

While server-side-rendering is highly recommended on all sites, it can result in Node.js having to pre-generate many HTML pages at once when a site has a large number of simultaneous users/bots.  This may cause Node.js to spend a lot of time processing server-side-rendered content, slowing down the entire site.

Therefore, DSpace provides some basic caching of server-side rendered pages, which allows the same pre-generated HTML to be sent to many users/bots at once & decreases the frequency of server-side rendering.

Two cache options are provide: botCache  and anonymousCache .  As the names suggest, the botCache is used for known web crawlers / bots, while the anonymousCache may be used for all anonymous (non-authenticated) users. By default, only the botCache is enabled. But highly active sites may wish to enable the anonymousCache as well, since it can provide users with a more immediate response when they encounter cached pages.

Note

Keep in mind, when the "anonymousCache" is enabled, this means that all non-authenticated users will utilize this cache.  This cache can result in massive speed improvements (for initial page load), as the majority of users may be interacting with cached content. However, these users may occasionally encounter cached pages which are outdated or "stale" (based on values of "timeToLive" and "allowStale").  This means that these users will not immediately see new updates or newly added content (Communities, Collections, Items) until the cache has refreshed itself.  That said, when "timeToLive" is set to a low value (like 10 seconds), this risk is minimal for highly active pages/content.


Code Block
languageyml
titleconfig.*.yml
cache:
  ...
  serverSide:
    # Set to true to see all cache hits/misses/refreshes in your console logs. Useful for debugging
Code Block
languageyml
titleconfig.*.yml
cache:
  ...
  serverSide:
    # Set to true to see all cache hits/misses/refreshes in your console logs. Useful for debugging SSR caching issues.
    debug: false
    # When enabled (i.e. max > 0), known bots will be sent pages from a server side cache specific for bots.
    # (Keep in mind, bot detection cannot be guarranteed. It is possible some bots will bypass this cache.)
    botCache:
      # Maximum number of pages to cache for known bots. Set to zero (0) to disable server side caching for bots.
      # Default is 1000, which means the 1000 most recently accessed public pages will be cached.
      # As all pages are cached in server memory, increasing this value will increase memory needs.
      # Individual cached pages are usually small (<100KB), so max=1000 should only require ~100MB of memory.
      max: 1000
      # Amount of time after which cached pages are considered stale (in ms). After becoming stale, the cached
      # copy is automatically refreshed on the next request.
      # NOTE: For the bot cache, this setting may impact how quickly search engine bots will index new content on your site.
      # For example, setting this to one week may mean that search engine bots may not find all new content for one week.
      timeToLive: 86400000 # 1 day
      # When set to true, after timeToLive expires, the next request will receive the *cached* page & then re-render the page
      # behind the scenes to update the cache. This ensures users primarily interact with the cache, but may receive stale pages (older than timeToLive).
      # When set to false, after timeToLive expires, the next request will wait on SSR to complete & receive a fresh page (which is then saved to cache).
      # This ensures stale pages (older than timeToLive) are never returned from the cache, but some users will wait on SSR.
      allowStale: true
    # When enabled (i.e. max > 0), all anonymous users will be sent pages from a server side cache.
    # This allows anonymous users to interact more quickly with the site, but also means they may see slightly
    # outdated content (based on timeToLive)
    anonymousCache:
      # Maximum number of pages to cache. Default is zero (0) which means anonymous user cache is disabled.
      # As all pages are cached in server memory, increasing this value will increase memory needs.
      # Individual cached pages are usually small (<100KB), so a value of max=1000 would only require ~100MB of memory. 
      max: 0
      # Amount of time after which cached pages are considered stale (in ms). After becoming stale, the cached
      # copy is automatically refreshed on the next request.
      # NOTE: For the anonymous cache, it is recommended to keep this value low to avoid anonymous users seeing outdated content.
      timeToLive: 10000 # 10 seconds
      # When set to true, after timeToLive expires, the next request will receive the *cached* page & then re-render the page
      # behind the scenes to update the cache. This ensures users primarily interact with the cache, but may receive stale pages (older than timeToLive).
      # When set to false, after timeToLive expires, the next request will wait on SSR to complete & receive a fresh page (which is then saved to cache).
      # This ensures receive stale pages (older than timeToLive) are never returned from the cache, but some users.
      # When set to false, after timeToLive expires, the next request will wait on SSR.
 to complete & receive a allowStale:fresh true 
Note
Keep in mind, when the "anonymousCache" is enabled, this means that all non-authenticated users will utilize this cache.  This cache can result in massive speed improvements (for initial page load), as the majority of users may be interacting with cached content. However, these users may occasionally encounter cached pages which are outdated or "stale" (based on values of "timeToLive" and "allowStale").  This means that these users will not immediately see new updates or newly added content (Communities, Collections, Items) until the cache has refreshed itself.  That said, when "timeToLive" is set to a low value (like 10 seconds), this risk is minimal for highly active pages/content.
page (which is then saved to cache).
      # This ensures stale pages (older than timeToLive) are never returned from the cache, but some users will wait on SSR.
      allowStale: true 


Authentication Settings

The "auth" section provides some basic authentication-related settings.  Currently, it's primarily settings related to when a session timeout warning will be showed to your users, etc.

...