Frequently update a system property using script.

[Jon23]

After reading SN Documentation, KB1000746, and several posts about the use of system properties with 'Ignore cache' checked [true], I am still unclear if it's okay (no impact to performance) to update a system property frequently using a script.

My requirement is to query records that have updated since the last time a process ran.  This processing job would simply get the existing property (date/time) value for use in the query, then update the property with current date/time ready for the next run.  The process runs hourly (may change to run every 15 minutes).

If updating a system property frequently is not a good idea, what is an alternative?  Creating a custom table that basically looks like the sys properties table?

[Sheldon Swift]

Hi @Jon23 - Your concern about frequently updating a system property in ServiceNow is valid, especially when it comes to potential performance impacts. Based on the information provided, using a custom table is the recommended approach. It avoids the potential performance pitfalls of using system properties with 'Ignore Cache' and provides a scalable, maintainable solution.

[HIROSHI SATOH]

What’s ‘Ignore Cache’ in ServiceNow? 

Based on the information provided, it is generally recommended to set the 'ignore cache' property to 'true' for system properties. This will prevent full system cache flushes when the property is updated, mitigating performance issues.

For your specific use case of storing a timestamp for a process that runs hourly, updating a system property with 'ignore cache' set to 'true' should be an acceptable approach. The performance impact of updating a single system property and flushing its specific cache is minimal compared to a full system cache flush.

There is also a limit to the number of new tables you can create.

[Sheldon Swift]

@HIROSHI SATOH - Agree the actual performance impact of using sys_properties is probably minimal. However, if a job runs on one node and updates the property, I'm uncertain if the other nodes will recognize the change until the cache is flushed. A custom table specifically designed to store the last run time of your process is much more scalable, allowing you to track and manage multiple jobs or processes while also supporting the storage of supplementary job data. Having said that, I agree there is a licensing consideration.

Another potential solution is to store the timestamp in a custom field on the sysauto table. While the syslog_transaction table contains the start time in the start_process_at field, and the sys_execution_tracker table has the start_time field, I would recommend using the time the job started the query, not when the job itself started or finished. Otherwise you could potentially miss some records.

[Jon23]

@HIROSHI SATOH @Sheldon  Swift  - Thank you for responding to this question.

KB1000746 article states:

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.

---

'This has a completely trivial impact on system performance' suggests (to me) that you can update system properties frequently, as long as 'ignore_cache=true'..... will it still be trivial if i have 100+ properties updating frequently 🤔

For my scenario i can probably avoid using system properties, however, my question still stands, as i know this will come up again.