You may have seen references to the Workgroup Server (WGS) cache. The cache is a key element of the meshIQ platform. Behind the scenes, the WGS periodically gathers the key data from the managed systems and refreshes the cache. Data that is volatile is updated more frequently than configuration data. In most cases, the cache update process is not perceivable to the end user. Extremely volatile data like temporary connections are not cached at all.
Why does the WGS use a cache? The cache is used for multiple purposes. By collecting the information once and sharing it, it reduces duplicate traffic to the managed system. If 5 users are trying to view the same data at the same time, it is only collected once. This also allows queries across the entire system without having to go to each server constantly. The data is also used to feed alerting and REST API requests, etc.
In typical usage, the delay interjected by the cache is not easily observable. One case where it can be seen is if a change is made using a method outside of meshIQ and then you immediately try to validate it. You can manually force the data to refresh as follows.
- Status data: Default 30 seconds
- The data will be refreshed without any interaction. Pressing the refresh option will show the latest data.
- Changed configuration data: Default 10 minutes maximum
- The data can be updated by selecting the Force Update option. This triggers to WGS to request the most recent data to update the cache.
- New or deleted objects: Default 10 minutes maximum
- These objects will be found during the next object refresh. If needed sooner, a discover request can be initiated to search for new or deleted objects.
- Changes made through the GUI or REST API are updated immediately upon request
- If the manager response is delayed, the refresh option will show changes
How low can you set the intervals?
- The status cache should not be set lower than 30 seconds. This already creates a lot of activity that the manager has to process. For test or less critical systems, you can increase the value to a minute or two noting the effect as described.
- The object refresh can be lowered, although the effort to discover that data needs to be considered. A value of 1 minute might be acceptable for your IBM MQ managers but would be very low for Kafka managers. For production systems that are not frequently changed or changed during scheduled windows, the value can be raised. A balance between getting data frequently versus how often it really changes ends up at 5-10 minutes being typical.
- For more info see Understanding WorkGroup Server Fact Collection and Publishing
This simplified diagram shows the data collected from the managed system, cached in the WGS and then being displayed by the end users, monitoring and REST APIs.