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

[MaxMixali]

ServiceNow – Frequent Cache Flushes due to Constant Property Updates

Scenario
--------
Frequent cache flushes are occurring because certain sys_properties are being updated repeatedly. Each property save triggers a platform cache invalidation across nodes, which can temporarily impact performance.

What to Review Before Enabling “Ignore Cache”
---------------------------------------------
1. Property Behavior & Purpose
- Identify which properties are changing often (sys_properties → filter by updated_on).
- Verify if these properties are updated manually or automatically by scripts/integrations.

2. Scope of Impact
- Check if the property is read dynamically by scripts or business logic.
- If used for real-time operations, disabling cache might create performance overhead.
- If it only controls a background process, it may safely be excluded from cache.

3. Change Source
- Review which script or flow updates these properties.
- Prefer optimizing or reducing update frequency instead of disabling cache.

4. Cluster & Node Behavior
- Cache flushes propagate to all nodes in a cluster.
- Review node logs for cache invalidation frequency.

When and How to Use “Ignore Cache”
----------------------------------
Setting ignore_cache = true prevents caching for that property. The value will be read directly from the database every time, avoiding cluster-wide cache flushes.

Enable ignore_cache ONLY when:
- The property’s value changes frequently (every few seconds or minutes).
- Real-time accuracy is critical.
- The property is not read excessively (not in high-traffic APIs or rules).

Avoid ignore_cache when:
- The property is used frequently in business rules or UI logic.
- The property’s value is relatively stable — fix the source process instead.

Recommended Approach
--------------------
1. Identify the properties causing cache flushes:
SELECT name, sys_updated_on, sys_updated_by FROM sys_properties ORDER BY sys_updated_on DESC;

2. Audit the automation or integration updating them.

3. Consider storing dynamic runtime data in a custom table rather than sys_properties.

4. Enable ignore_cache only for specific keys like:
- Integration tokens or timestamps updated frequently
- API counters or runtime toggles

5. Monitor after enabling ignore_cache to confirm stability.

Best Practice Summary
---------------------
| Goal | Recommended Action |
|------|--------------------|
| Reduce cache flushes | Stop frequent updates or enable ignore_cache only on specific properties |
| Maintain performance | Avoid disabling cache on properties read by UI or BR logic |
| Separate dynamic data | Move fast-changing values to a custom table |
| Audit & monitor | Regularly review sys_properties updates and logs |

Conclusion
----------
Using ignore_cache is safe for a few frequently changing, non-critical properties. However, the best practice is to eliminate the root cause — unnecessary updates — rather than rely on ignore_cache as a long-term solution.

[MaxMixali]

Frequent cache flushes in ServiceNow typically occur when system properties (sys_properties) are modified, as each update triggers a platform-wide cache refresh. While the ignore_cache flag can help in some cases, it must be used carefully since it changes how property values are retrieved.

Here’s how to approach the issue:

---

🔍 Step 1: Identify the Properties Causing Frequent Flushes

1. Navigate to System Diagnostics → Cache Log or sys_cache_flush table to check recent flushes.

2. Use Audit History on sys_properties to identify which properties are frequently updated.

3. Determine whether these properties are updated by background jobs, integrations, or scripts (e.g., Script Includes or Business Rules).

---

⚙️ Step 2: Understand the Role of

ignore_cache

When you set “Ignore cache” = true on a property, ServiceNow skips caching and retrieves the value directly from the database every time it is called.

• ✅ Use when the property value must always be real-time (e.g., toggling feature flags dynamically).

• ❌ Avoid when the property is accessed frequently (hundreds/thousands of times per transaction) — this can cause DB performance degradation.

---

🧩 Step 3: Review Before Enabling

ignore_cache

Check:

1. Read frequency — If the property is read often (e.g., in Glide scripts, flows, ACLs), avoid enabling ignore_cache.

2. Update frequency — If it changes often but read infrequently, ignore_cache may help avoid frequent cache invalidations.

3. Code dependencies — Search in scripts using the property (gs.getProperty('property.name')). If it appears inside loops or client scripts, ignore_cache is not recommended.

4. Impact analysis — Use Performance Analytics “Scripted API usage” to measure how often properties are called.

---

🧠 Step 4: Best Practices

• Consolidate updates: Group property changes into controlled intervals (e.g., through scheduled scripts).

• Minimize dynamic updates: Avoid continuous updates from integration scripts or external triggers.

• Use a custom table instead of sys_properties for high-frequency data; cache it separately with GlideCacheManager.

• Use system property categories logically — ensure that only configuration data (not runtime data) lives in sys_properties.

• Monitor DB performance after setting ignore_cache = true — each access will query the DB.

---

✅ Recommendation

Do not use ignore_cache as a blanket solution.

Instead:

• Use it only for a small number of dynamically changing properties.

• For frequently updated or operational flags, move them to a custom config table and manage caching via script includes or GlideCache.

---

In summary:

Enabling ignore_cache may reduce cache flush frequency, but it’s not a best practice for performance-sensitive or frequently accessed properties. The better long-term approach is to isolate dynamic properties into a dedicated configuration model and minimize property-level updates on production.