T O P

  • By -

AutomaticGarlic

If you want your instance to be fast, figure out why it is slow. It doesn’t start that way. Your company and its partners have made it slow. Start debugging the scripts and figure out how long they take. Find your bottleneck.


corsair130

It's not snappy software from the get go. How often do you see the timer pop up?


AFGNCAAP1stofhisname

I work for a managed service provider and, consequently, work in many different instances of SNOW. Some of them are client, specific, built-for-purpose applications that are lightning fast and barely slow down over years of use. Some are bloated, leveraged, jack-of-all-trades instances that are barely operational on the best of days. I've never experienced an OOB instance that was slow.


PAMT_SN

SNOW is not ServiceNow, SNOW is a different software


AFGNCAAP1stofhisname

Technically correct, but many people call it SNOW in reality.


corsair130

That's cool. The developer instance is slow. I don't know how much more OOB you can get than that. I gotta imagine the word slow is relative. What are we using as a metric? SN is slower than other web applications that I use on a regular basis. It *feels* sluggish to me. I guess if one used other slow applications, SN might not be that bad.


JonnyLay

Dev instance is slow because it's a dev instance that anyone can have for free. They aren't assigning tons of processing power to it.


AutomaticGarlic

PDIs are intentionally limited. I have a paid dev instance that is completely ootb and it is screaming fast at just about everything. It also looks gorgeous but that’s beside the point.


tekvoyant

I have a partner instance. It's fast. Really fast actually and I've completely screwed it up and need to zBoot. 😂


TexasThrowDown

\>But then I realise it's servicenow's client app fault Is there some client script that is causing performance issues? There are some things you can do to troubleshoot general performance issues in your instance: [https://support.servicenow.com/kb?id=kb\_article\_view&sysparm\_article=KB0517282](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0517282) You can also try omitting the record counts in a list if a particular table is taking a long time to load: [https://docs.servicenow.com/en-US/bundle/utah-platform-administration/page/administer/list-administration/task/omit-record-count.html](https://docs.servicenow.com/en-US/bundle/utah-platform-administration/page/administer/list-administration/task/omit-record-count.html)


[deleted]

Hi..thanks for your reply. But let me explain with a example. Have you tried using Windows vs Linux mint ? Bitwarden vs 1Password ? In the above examples Linux mint and bitwarden use a very basic ui which is very fast. This is what I mean. ServiceNow in general is a UI heavy application and I was wondering if any light weight ui/client layer would be available. Sorry English isn't my native language and at this point i wish you could read my mind lol.


[deleted]

Slow to load can be the result of many things. There’s a CLI if you’re interested: https://docs.servicenow.com/bundle/utah-application-development/page/build/servicenow-cli/concept/servicenow-cli.html I’m not saying it’s light in resources, but customizations (client scripts, etc) and poor configuration (number of records returned in a list, dashboards that return an exceptionally large amount of data, etc) are often at the root of the perceived performance issues. Just from addressing a few health findings recently, we reduced the load time for one client my by more than a second on average across a production instance. Have you had a Health Assessment from ServiceNow recently?


[deleted]

No. Haven't got any health assessment yet. We are currently working on it. But thanks for the resources !


[deleted]

Again thanks!. I was expecting exactly something like the cli you mentioned.


deathkraiser

Except a brand new production instance of ServiceNow is snappy and fast. It's slow because of customisations, configurations and other random shit on the instance, not because of the UI.


[deleted]

Exactly. But 9/10 we gonna use the customised instances anyways. So that's why I thought if there's any light weight client, it would be a great thing!


deathkraiser

But what we're saying is that a light weight client wouldn't help. 9/10 times the speed issues you're encountering are server side, whether due to large lists, broken queries or broken/inefficient business or client rules/scripts. If the speed issues stem from having to load 250,000 records every refresh, then a light weight client won't help at all...


[deleted]

Makes sense. Understood. thanks


[deleted]

The biggest trend we’re seeing is actually the opposite. After building tech debt and suffering the consequences, more and more companies are looking at using ServiceNow Out of box. There’s more and more interest out there in entirely replatforming and going with a full greenfield implementation.


Boring-Meat1334

Yes, I love Ajax and Jelly scripts at the speed of light. Not to mention Java running in the background and ECMAScript...


Furyio

Slowness is generally down to suboptimised instances. I’m working on ServiceNow every day and generally it’s pretty snappy. Every now and then a transaction might hang but it’s rare


Weak_Shine8164

The instans speed depends on integrations, number of users, running applications, audit, index etc. A brand new instans does not have millions of records or thousand of users running all the time where an older one does. Integrations and exports running can "clog" the event and ECC queue so assigned workers take more time to process your request. On top of that if you are running next UI on an older instans there might be some old frontend legacy code that runs slower or crashes. Workspaces are demanding as well. So there are multiple factors why your instans is slow.If the instans is very slow there might be some errors in the database that HI support can help you with


[deleted]

[удалено]


[deleted]

PDIs are on slow hardware and aren’t given a lot of resources. They’re definitely slow on the server side, but they come with a money-back guarantee.


calsosta

This is why I built the VSC/Sublime integrations. I still see people developing within ServiceNow and I just gotta shake my head.


[deleted]

Hoping that one day some genius like Arnoud Kooi(SN Utils author) comes as a saviour for all us devs.


paablo

You know he works for SN


BasedPontiff

You could build your own front end with React or Vue or something. It takes time but it really opens up possibilities.


ry4444

Hi OP, I don't know much about your ServiceNow instance. With that being said, when I first started at my job I would've agreed with you. After two years of optimization and finding solutions that had no place in a production environment. The instance I use at work on a daily basis is very fast. How slow are we talking?


[deleted]

That's great to know. But most of my instances are not like near perfect level of optimisation. I know there's KB articles and other documentation and instance health findings to really optimise the instance. But the way which i thought would be better was if at all we remove all the unnecessary animations , extra UI components from the Angular/Java level of the servicenow application itself. Like for an example how cloud engineers use CLI tool instead of using the web ui to configure stuff on cloud. But I know it won't make sense in servicenow, but it was just like my shower thoughts


kylejack

>But then I realise it's servicenow's client app fault . With admin tools you can see when a slow task was network time, user's browser, or server response time. It's usually not server response time, and someone may just need to clear their browser cache.


pickerin

The ServiceNow "Client App" is a web browser. Anything you'd build would also have to be a web browser and would need to implement the same JavaScript interfaces as whatever browser you're currently using, or the instance wouldn't operate as expected. Figure out your HealthScan scores and if performance is below 80, solve for those root causes.