Washington D.C.'s Changes "Under the Hood"

[laurenmcmanamon]

In TechNow, we talked a lot about the new feature enhancements made in the Washington D.C. Release. However, with only 60 minutes, some things were nixed for time. One concept left on the cutting room floor was that of platform improvements made on the back end. While it comes with no new button or designer or experience, these changes will greatly impact your experience as a ServiceNow developer, so let me give you the rundown.

There are 2 big changes, and both of them pertain to pressure placed upon an instance's nodes. Each ServiceNow instance is made up of a collection of these application nodes. These nodes handle the requests performed by your instance and have a limited capacity for performance. Think of it like the chocolate factory episode of I Love Lucy - when too many requests come in, performance suffers and things get dropped. Instead of ruined chocolate, on a ServiceNow instance, this degradation in service comes in the form of slow response times and hang-like conditions. 

 

Central Scheduler

To kick things off, we have the introduction of Version 3 of ServiceNow's Centralized Scheduled Job Delegation. Our developers found that in high node-count instances, there was a common culprit causing worker starvation: mutex contention. Contention occurs when one thread has to wait for another thread to finish using a resource. Contention problems can occur if your application uses too few mutual exclusions (mutexes) to protect access to a large number of resources. In addition to this, there was inefficient utilization of the scheduler workers for long-running jobs​ and short-interval jobs. This new scheduler fixes all three issues! 🎊

While standard Washington D.C. users will not see visible changes in the UI, they will feel the benefits of this higher worker thread utilization (especially on busy/larger instances). Large job floods will no longer degrade the throughput of activity, nor will long-running jobs block other jobs with reassignment. The result will be a more efficient instance for all! 

 

Memory Pressure Remediation

Another way nodes are being helped is with the remediation of memory pressure. A scheduler can assist in the relief of memory pressure by reducing the size of the worker thread pool (up to a 50% reduction) to decrease its memory footprint. Once the memory pressure has eased the scheduler can ramp up the worker thread pool back to its normal size.​

Ergo, this functionality was added to ServiceNow instances as of the Washington D.C. release. Only maint users will be able to configure the scheduler memory remediation or view the log of jobs suspected to be contributing to the pressure. This feature is not intended to be visible to general-purpose users, but similar to the above improvement, its results will surely be felt by them!