While this article doesn't mention Glide Properties (the sys_properties table), it seems prudent to add a note about them here since they are a server-side method of caching data that can be used to improve performance. One particularly confusing topic regarding Glide Properties is the performance impact incurred when they are changed. When you change a Glide Property it can cause a system-wide cache flush leading to potentially severe performance degradation for anywhere from 5 to 30 minutes. In some rare cases it can even cause hours of impact. This has been observed in cases where node are down hard enough during cache flush that the load balancer takes them offline, causing session imbalance. Let us explain why.

 

ServiceNow is a clustered platform with multiple "nodes" or JVMs working as a single "instance" of ServiceNow (e.g. acme.service-now.com). Properties (records in the sys_properties table) are cached in node memory. This is a way of avoiding database calls for commonly accessed values. When a property is changed on one node, it tells all the other nodes to dump their property caches and get the new value of all their properties from the database again. This has a completely trivial impact on system performance. This part happens regardless of if the ignore_cache field is set to true or not.

 

However, if ignore_cache is set to false - this was the default value until Rome or perhaps San Diego release - then we not only flush the specific cache related to properties, but we also flush the whole Glide System cache!! Let me say that again and, please, pay attention to the double negative. If a property is set to not ignore the cache then we are telling it to flush the whole Glide System cache! This is what triggers the significant performance impact. So why would we do it? The reason that this cache flush is done is so that we make sure to flush any dependencies or stale values in other caches that might be related to the old value of the property that was just changed.

 

For example, imagine that you have a UI cache that stores the rendered HTML of a page on the server-side, on a per session basis. The purpose of a such a cache would be to avoid rendering the same page over and over for the same user. Now suppose further that the way the HTML renders depends on the value of a property that was just changed. If we don't flush this UI cache then the old value of the property will still be getting used in the rendered HTML and any changes you expect to see in the UI based on the change of the related property would not reflect in the UI until the user starts a new session - i.e. until they log out and log back in. In this scenario you would want to make sure that ignore cache is set to false so that we will not ignore the cache flush, thereby ensuring that any dependent cache would also be flushed.

 

So, in summary, if you have a property value that will be frequently updated (more than, say, once a month) and you know that there are no other caches that might depend on the value of the property, then set ignore_cache = true. That way the system will only flush the property-specific cache when the property is updated and not the whole Glide System cache. Note that the property-specific cache flush is a fairly expensive operation. Every node in your cluster will need to query the sys_properties table and pull back every single value and put it in the cache. In the meantime an exclusive lock will be held in the application layer and any thread attempting to access a Glide Property will be frozen until the cache finishes rebuilding. At high enough volume, just flushing the property cache can cause an outage. Glide Properties should not be used to hold transient state values. Even with ignore_cache set to true, they probably not be used for values that change more than once a day. Alternatively, you could just use some table besides sys_properties in which to store the value. However, we recognize that if you were to use a new custom table that would incur licensing charges and so this might not be a viable option. Consider if there is some other way to accomplish your goal, perhaps there is an existing configuration table that can be re-used.

 

Best regards, your performance team

ServiceNowPerformanceGTS

 

NOTE: This whole discussion about sys_property.ignore_cache is only in relation to ServiceNow server-side caching. It has nothing to do with the caching mechanisms implemented on the client-side; within Browsers/User Agents