How not to slow down ServiceNow instance

[RahulY00040]

Hello Friends,

Lately I was thinking about how can I make ServiceNow platform function smoother or better ?

And as I am a big fan of Inversion Mental model, i thought of reversing the question about what can i do to slow down ServiceNow instance and to impact its upgradibility ? So, i came across things such as substandard or slow queries using query before business rules, extensive customizations, poor development standards, etc.

Could you please add your points as well. 

Thanks,
Rahul

[Mark Manders]

What is your question behind the question? Because it sounds weird to check on what to do to slow something down to not slow it down. Using bad practices slows it down, so don't use bad practice? The shore answer of that is: use best practices.

Customization impacts upgradability. Just don't do anything that isn't necessary and with every requirement put the pros and cons next to each other. Is the functionality worth the impact it will have? 

It just doesn't help to make a list of things that slow down an instance in an attempt to keep it running smoothly, because it takes extra time. 'Substandard queries will slow it down' just means that you should standardize your queries. Telling people what they should do is a more positive approach than telling people what they shouldn't do.

[Maik Skoddow · Accepted solution]

Hi @RahulY00040 

I really appreciate your use of the inversion mental model here, it's a powerful way to uncover blind spots and reinforce best practices.

You're absolutely right that things like poorly written queries in before business rules, excessive customizations, and lack of standards can negatively impact performance and upgradability. I'd be happy to add a few more common pitfalls that I've seen over the years:

• Inefficient use of GlideRecord in loops: Especially when querying within a loop, this can lead to performance bottlenecks.

• Client-side heavy UIs: Too many Client Scripts, DOM manipulations, or synchronous GlideAjax calls can degrade user experience.

• Uncontrolled growth of data: Not archiving or cleaning up tables (like syslog, sys_audit, custom logs) can lead to database bloat.

• Customizations in core tables and update sets without governance: These make upgrades riskier and harder to test.

Your approach is insightful because it forces us to confront the real impact of our design and development decisions. It's much easier to recognize a "bad practice" in hindsight than to always know the "best practice" in advance. Framing it this way can help teams become more intentional and critical about their implementations.

Thanks again for sparking such a thoughtful conversation.

Maik

[Chaitanya ILCR]

Hi @RahulY00040 

Refer this Blog 

Instance Performance Maintenance and Administration 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya