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.SymptomsWhen you change a Glide Property it can cause a system-wide cache flush, usually leading 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 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.ResolutionSet ignore_cache = true for custom properties.