When to use 'ignore cache' on 'sys_properties recordsIssue Summary: If you create a new system property in your ServiceNow instance, you should almost always have 'ignore cache' set to "true" on the 'sys_properties' record. If a property value is changed that has 'ignore cache' set to false, then it will trigger a whole Glide System cache flush, potentially resulting in system-wide performance degradation as the caches are rebuilt. NOTE: This article is written to explain the behavior of system properties and instruct customers when creating new system properties or updating custom properties. The 'ignore cache' field of out-of-box properties, on the other hand, should not be changed unless otherwise directed by ServiceNow.SymptomsIf 'ignore cache' is set to false, when you change a Glide Property, it will cause a system-wide cache flush. This usually leads to mild performance degradation for anywhere from 5 to 30 minutes. In some very rare cases, this may result in severe performance degradation with average transaction response times increasing twofold or even threefold. The degradation experienced is very similar to that of applying an Update Set. You should take the same level of caution when changing a Glide Property that has 'ignore cache' set to false as you do when applying an Update Set.ReleaseAll ReleasesCauseTo understand why this happens you need to understand that ServiceNow is a clustered platform with multiple "nodes" or JVMs working together as what appears to the internet as a single "instance" of ServiceNow (e.g. acme.service-now.com). Properties are cached in node memory, meaning each node in the cluster has its own copy of each property. This is a way of avoiding database calls for commonly accessed property values. When a property is changed on one node, the other nodes 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 the Rome 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. NOTE: Even if a property has 'ignore cache' set to true, there is still some small impact to the instance. This is because every time that a property changes, even if 'ignore cache' is set to true, all the properties in the system need to be reloaded from the database. Depending on how many properties are in your database, the query to load those properties may take a few hundred milliseconds to complete and a few more to loop through the results and update the cache. While the property cache is being rebuilt, any other thread that attempts to access any property will be frozen. For this reason, it is not recommended to use Glide Properties to store values that change frequently - even if you have 'ignore_cache' set to true. Any value that is likely to change more than once a day should probably be stored in some other table.ResolutionSet ignore_cache = true for custom properties.