nullEDGE – Performance tuning with Pawan Kumar Singh

How often do you hear people saying “ServiceNow is too slow”?

Pawan shares some quick wins to make them happy, and a list of topics to explore and avoid such complaints in the future.

Key takeaways

Defer related list loading

Related lists are often responsible for most of a form’s load time.

Pawan mentions two system properties:

  • glide.ui.defer_related_lists: I’m not sure this one is still working after Fuji. I’ve just tested in a PDI, and I can’t see any effect. I cannot find any reference in the official documentation either.
  • glide.ui.related_list_timing: This is actually a User preference that you can set up globally, but can be overridden by the users:
    • default: Related lists load when you open the form, which is the default setting.
    • deferred: Related lists load after the rest of the form loads.
    • ondemand: Related lists load on demand.

I’m still surprised “deferred” is not the default behaviour in new instances!

Keep the landing page lightweight

Avoid at all costs having a heavy dashboard as the login landing page!

Make sure glide.login.home points to a simple welcome page.

Not mentioned in the video, but I found a user preference option I was not aware of that users can override. You can find it in “Preferences → User Experience → Current start page”.

  • Use the default.
  • Use dashboards.
  • Use the page that I’m on now.
  • Continue where I last left of.

Limit the number of rows displayed in list views

Pawan mentions glide.ui.per_page, which controls the options that appear in the “Show rows” menu and recommends keeping it in the 20-50 range.

Don’t tell anyone, but the system property only controls the options available in the menu!

You can still modify the rowcount user preference and show 333 rows per page because… what could go wrong?

Some other recommendations

Besides the quick wins, he also recommends:

  • Follow scripting best practices (e.g. avoid synchronous calls and having too many onLoad scripts).
  • Leverage instance scan (e.g. remove forgotten logs).
  • Explore archival rules, indexing, chaching.
  • Monitor slow things: queries, transactions, scripts.

And something I have never thought about: There might be a hardware problem!

The nerd in me missed some numbers (e.g. “this form took 20s to load, but after changing this property, it’s 1,2s”). It’s easier to internalise these ideas when you see/feel the pain.

But even without numbers, the message is clear: remember not to load unnecessary things!

References

1 thought on “nullEDGE – Performance tuning with Pawan Kumar Singh”

  1. Pingback: nullEDGE advent calendar » Rubén Ferrero

Comments are closed.