Frequent cache flushes negatively impact instance performance.

[1_DipikaD]

Hi All,

Frequent cache flushes are happening on the instance due to a few properties being updated constantly.

Please suggest Which things need to be checked while reviewing and enabling the ignore cache for these properties. Is enabling ignore cache could be best practice for this or need to follow  different approach ?

Thank You

[Kieran Anson]

You can add the 'updates' column to your sys_properties list layout to see how frequently it has a value changed. 

[1_DipikaD]

Hi @Kieran Anson 

A custom system property is being used in 6 business rules and the ignore cache = false now . Would this have -ve impact on instance performance ? Additionally, I have one more custom property which is not used in any server side script , would that have any performance impact ?

Please let me know if you need more info .

Thank You

[Kieran Anson]

It will depend on how frequently they're updating. If the BR is causing the property to change on every update, and the triggering record is updated regularly then yes. Even if ignore cache is set to false, SN still has to clear the system property cache which has a performance impact.

[Ankur Bawiskar]

@1_DipikaD 

I agree with what @Kieran Anson mentioned.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[MaxMixali]

ServiceNow – Frequent Cache Flushes from Property Updates: Should You Use “Ignore cache”?

Problem
Frequent updates to sys_properties are causing repeated cache flushes across the node/cluster, impacting performance. You’re considering enabling the “ignore cache” checkbox on those properties to reduce flush churn.

Short answer
- Enabling **Ignore cache** on a property stops that property from being cached by the platform’s property cache. It avoids cache invalidations when that one property changes, but it forces a **DB read on every access**.
- This is **not** a blanket best practice. Use it **surgically** on a few low‑traffic properties that must change at runtime and are read infrequently. For high‑traffic reads, “ignore cache” can be worse than periodic flushes.

What happens when a property changes
- Updating a record in **sys_properties** triggers a **property cache rebuild** (and on multi‑node, a cluster message to other nodes). If updates are frequent, you’ll see frequent cache churn.
- Some apps read properties often (e.g., in BRs, Interceptors, UI Policies, Widgets, Flows). Cache churn + high read frequency can amplify latency.

Decision framework: When to set “Ignore cache”
1) Read Frequency
- Rarely read (e.g., only by a scheduled job / admin UI path) → Safe to mark “Ignore cache”.
- Frequently read (each request, each transaction, or tight loops) → Do **not** mark “Ignore cache”.

2) Change Frequency
- Changes many times per hour/day → Consider alternatives; avoid using sys_properties as a real‑time switch.
- Changes occasionally (few times/day) → Leave cached; batch updates if possible.

3) Performance/Load Profile
- Single node / low load → “Ignore cache” impact is smaller.
- Multi‑node / high load → DB hits from ignore_cache can be costly.

Safer alternative patterns (recommended)
A) Feature Flag / Config Table + Lightweight App Cache
- Create a small app table (e.g., **u_app_config**) to store fast‑changing flags.
- Build a Script Include that caches values in **GlideCache** or a simple in‑memory variable with a short **TTL** (e.g., 30–120 seconds). Only DB‑hit when TTL expires.
- This avoids global cache flush and isolates churn to your app.

B) Property Staging + Scheduled Apply
- Keep an “admin‑editable” value (staging) and a “runtime” value.
- A scheduled job copies staging → runtime at controlled intervals (e.g., every 5–15 minutes), minimizing flush frequency.

C) Node‑local Overrides (only if acceptable)
- If the value only needs to change on **one node**, store a node‑local configuration (e.g., a node property or a file). This avoids cluster broadcast but sacrifices uniformity.

D) Batch Updates
- Bundle multiple property edits into a single change window to cause **one** flush instead of many small ones.

Checklist before enabling “Ignore cache”
- [ ] Confirm **read frequency** (log callers or wrap gs.getProperty in a helper to count calls).
- [ ] Confirm **call paths** (is it inside a hot path like a BR on task insert/update or a portal widget server script?).
- [ ] Measure with ATF or simple timers before/after.
- [ ] Verify **DB health** (indexes on sys_properties are standard; DB latency matters when ignoring cache).

Code patterns

1) Simple helper with mini‑cache + TTL (best general approach)
var AppConfig = (function() {
var cache = {};
var TTL_MS = 60000; // 60s
function now() { return new Date().getTime(); }
function get(name, defVal) {
var e = cache[name];
if (e && (now() - e.t) < TTL_MS) return e.v;
// Read from sys_properties (cached normally)
var v = gs.getProperty(name, defVal);
cache[name] = { v: v, t: now() };
return v;
}
return { get: get };
})();

// Usage:
var flag = AppConfig.get('x_app.my.feature.enabled', 'false') == 'true';

2) DB‑backed feature flag with TTL (no global property cache flush)
var FeatureFlags = Class.create();
FeatureFlags.prototype = {
initialize: function() { this._ttl = 60000; this._cache = {}; },
_getNow: function(){ return new Date().getTime(); },
get: function(code, defVal) {
var c = this._cache[code];
if (c && (this._getNow() - c.t) < this._ttl) return c.v;
var gr = new GlideRecord('u_app_config');
gr.addQuery('u_code', code);
gr.setLimit(1);
gr.query();
var v = defVal;
if (gr.next()) v = gr.getValue('u_value');
this._cache[code] = { v: v, t: this._getNow() };
return v;
},
type: 'FeatureFlags'
};

When to absolutely avoid “Ignore cache”
- Properties used in **every request**, **every GlideAjax**, **every Flow action**, or inside **loops**.
- Properties used by **security/ACL** logic or **table CRUD** that execute frequently.
- Any value referenced by **portal widgets** on high‑traffic pages.

Observability
- Add temporary logging to count property reads and change frequency.
- Monitor **node memory** and **DB load** before/after change.
- Watch node messages and cache flush events in logs when properties are changed.

Summary
- “Ignore cache” is a surgical tool: use it only for **infrequently read** but **frequently changed** properties.
- If a property is read often, create a **custom config table** + **short‑TTL cache** (best of both worlds).
- Reduce flushes by **batching updates** or **scheduled apply**, not by forcing every read to hit the DB.