Designing for Performance Part 3

[Chris Pearson]

Let's continue where we left off with our designing for performance series. Another common bottleneck the ServiceNow Account Escalation Engineering team sees is with application node memory. Remember, each node typically has 2 GB of heap space. 300-500 of that is usually cache (dictionary, forms, labels, scripts, etc). As the usage of memory inches higher towards that 2 GB limit, the node must spend more time performing 'garbage collection' which leads to performance degradation.

What can cause memory issues? Again, we're pointing the finger at poorly written code in most cases. Do you have a recursive function which has found itself in a long or infinite loop? Are you querying a table and writing records to an array that is massive? Writing code which keeps the memory limit in mind will ensure you don't hit this type of performance bottleneck.

Consider the difference in memory usage to store 100,000 full Glide Records vs. an array of 100,000 sys_id's. The Glide Records eat up a full gigabyte of memory, while the 100k sys_id's in an array only take up approximately 3 MB. Can you write your code efficiently so as to not bring SN to its knees?