Designing for Performance Part 2

[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 semaphore availability.

Each application node of the instance has 16 UI (default) threads. When a slow transaction is introduced and is used frequently it can quickly eat up the queue of available semaphores. When this happens the user can experience extremely poor performance. Think of clicking on a UI Action which normally triggers a flow, but that flow doesn't fire...and we just sit there and wait and wait and wait.

To mitigate this issue, the best thing we can do as architects and developers is to properly test our code and flows. Review the transaction logs and look at all of the long running transactions to understand the question...why? What part of that transaction is the long pole in the tent? Is it a database issue (poorly written queries/code), is it doing too much on the client side, or maybe some custom DOM manipulation which might be unnecessary?

Are you simply relying a little too much on the use of flows in SN? Perhaps an event driven solution with script actions are a better design pattern for very large numbers of transactions firing one after another? (I'll do another blog on this topic soon)