Caching
Caching is used to improve WebUI response times. Cached data is processed, stored, and refreshed at a specific interval.
(While most WebUI data appears in real time, a few WebUI counters, such as the number of applicable devices, require complex calculations.) Processing time goes up as device counts go up, and large deployments can be affected. The cached values are:
- Applicable Patch count on the Device list
- Applicable Device count on:
- the Patch list
- the Software Package list
- the Custom Content list
- Document Overviews for individual patch, software, and custom content.
- Open Deployment count on:
- the Content list
- the Custom Content list
- the Patch list
- Deployment information on the device list
_WebUIAppEnv_SP_QUEUE_CONCURRENT The setting _WebUIAppEnv_SP_QUEUE_CONCURRENT also affects WebUI caching. It limits the number of stored procedures that run simultaneously per App in the background that update cache values while users are browsing the WebUI. The default value is 5.
Cached values are flagged. For example, the relevant patch count on the Device list may display a
message, Last updated 4 minutes ago. Click here to see the most up-to-date data.
Refreshing
the browser retrieves the latest data from the cache.
The default refresh interval is 10 minutes. This interval, also called the cache Time To Live (TTL) value, determines how often cache results are invalidated. Ten minutes is considered a good trade-off between cache freshness and response time impact.
To change the interval, use the client setting _WebUIAppEnv_CACHE_TTL. Modifying the TTL value requires significant understanding of system load and operator concurrency, and is only recommended for administrators willing to monitor and tune the configuration. Enter the wanted interval period in seconds. The default interval is 600; the minimum interval is 180 (3 minutes).
Increase the interval to establish longer periods between cache refreshes. Customers with large deployments and lots of activity can lengthen the interval for fewer refreshes and lower impact on system resources. Activities that change applicable counts will consume more resources. These include:
- Increasing the number of devices reporting in to BigFix.
- Intensive patching activities, for example, on Patch Tuesday.