We have recently come to understand that the cache data sent to Integrity clients is reloaded all at once any time one of the cache values changes. With the exception of the cache for IBPLs refreshing for IBPL changes, though even that implementation is far from optimal, especially considering that IBPL pick options can take up the majority of the cache data. If the user and group cache is refreshed, then all other caches are refreshed as well. Presumably if a project is created then all caches have to refresh too.
In total the caches of our production server, compressed, are several megabytes in size, even after we have worked to reduce them. This is a slight problem in buildings with poorer than average connection, and a major problem for international users. Slowness related to networks is a widespread problem for our users in Integrity, reducing the usefulness of the tool.
I know of two main approaches to mitigate this issue. The first would be to separate the caches so that they are updated only from changes that affect them directly. If the user and group cache is refreshed then send updates only for that cache, and not the field cache. The second would be to send only the differential data. The client would record a timestamp or cache version number whenever they receive data, and the server would note this in order to send what has been updated since that time.
For the IBPL cache alone it would be beneficial if each field could be considered separately when updating the cache. Do not update the fields which have not had their values updated.
