Skip to main content
Later page load times are much quicker than the first load due to caching. The “Cache Warming” feature allows a group of users to have their cache warmed every hour. This improves their first page load and avoids that initial long wait for the page to render when logging in.

​
Enabling the Cache Warming Feature

  1. Navigate to your Curator backend > Settings > Curator > Portal Settings > Features tab.
  2. Enable the “Cache Warming” feature at the top of the Functionality section.
  3. In the “Priority Group for Cache Warming” field, choose a Frontend Group with less than 200 members. The options should already be limited to applicable groups. For more information about creating Frontend Groups, visit the doc.
  4. Hit “Save.”

​
Notes

  • Every hour the members of the chosen group will have their cache warmed. This is ran every hour in case another process has cleared the cache such as logging out or making a configuration change.
  • The group has to contain less than 200 members because the process to warm the cache is intensive. Warming for more than 200 members might bog down the queue that runs scheduled processes, preventing other important functions to run.

​
Common Cache Log Errors

Cache warming runs asynchronously for each user in the Priority Group, so it is normal to see warming-related entries in the System Log. The entries below cover what is non-fatal and what requires action.

​
”Failed to warm cache for user X”

A single Failed to warm cache for user X entry is non-fatal and affects only that user’s next page load. The most common cause is a transient platform API timeout (for example, a slow response from Tableau Server, Power BI, or ThoughtSpot during the warming pass). The affected user will simply experience the normal uncached first-page-load time on their next visit, after which their cache will be populated as usual. No action is required unless the same user fails to warm on multiple consecutive runs, in which case investigate the upstream platform’s availability and response times for that user’s content.

​
Repeated OOM (Out Of Memory) Failures During Warming

If the System Log contains repeated out-of-memory failures originating from the cache warming job — for example, PHP fatal errors mentioning Allowed memory size of N bytes exhausted inside the warming schedule — the configured Priority Group for Cache Warming exceeds the memory budget available to the queue worker on this server. To resolve this, do one of the following:
  1. Reduce the size of the Priority Group for Cache Warming so the cumulative cost of warming all members fits within the queue worker’s memory budget.
  2. Move only the highest-priority users into the group and accept the normal uncached first-page-load time for everyone else.
  3. As a temporary measure while right-sizing the group, enable the Disable All Cache Warming toggle on the same Portal Settings screen so the warming job stops running entirely until the group is reduced.