You don't always need to clear the cache

[Shahed Shah1]

During my time in ServiceNow Customer Support and reviewing many questions on the Community, there's always one thing that got me reeling for a brief moment. Cache flush. This is because whenever you clear (or flush) the cache, it's purging more than properties and dictionary data, in addition to calling the Garbage Collector of the JVM (which hits the CPU). The performance hit you face happens when the Instance is rebuilding itself. Everything. You can read more about platform performance in the Product Documentation.

When is it not a good time to flush the cache?

Personally, I do cringe at the thought of performing a cache flush when the form layout for a particular table seems off or regularly done during development work "just to make sure the platform is up to date." Doing this regularly or on a high frequency is going to hit the performance of your Instance - no doubt. So, please don't entertain the thought of creating a scheduled job in the hopes of this being a refresh without doing a restart - if you do and were advised to, then you really have to think frequency.

When is it a good time to flush the cache?

While I can't give you a precise science of when it is the best time to clear the cache, I can give you examples of when it makes sense to me (again this is my opinion - not fact). I have seen on occasion, the entire UI on one node was scrambled and bucket loads of users were impacted - in this case, clearing the cache was required to provide relief. In fact, I won't argue with doing it if you are faced with a P1 scenario.

How do you flush the cache?

Now that you're clear on when you should or should not flush the cache (or just tired of me rambling), I will go over how it's usually done. There are two methods for clearing/flushing the cache:

1. Appending cache.do to the Instance URL (so https://instance.service-now.com/cache.do)
   1. Or type "cache.do" in the navigator
2. Running gs.cacheFlush() in the Scripts - Background module

But what is reeaaaally important is that you try get to the bottom of why the issue happens in the first place, especially if this is a common occurrence. So let Customer Support know about this and they will work with the developers, if necessary, to identify a potential defect in the platform. The engineers in Customer Support will most likely go into the Node Logs first, so make sure you provide the date, time and user(s) at the time the issue was encountered. In fact, I'd suggest you also give the time zone just so they can ensure they are looking at the right time window in the log files - we do have a global base so it would make sense to consider time zones in day to day troubleshooting.

How to clear the cache for a specific issue

Ok, ok. I know that I can't tell you to never ever do this and have given some ideas when it's necessary. But, if you encounter a situation where it's needed, then you can use the second method (mentioned earlier) with a little trick. You can provide a parameter to this function call to clear a particular area of the cache. Isn't that sweet? For example, gs.cacheFlush("syscache_realform") will clear the cached version of form layouts (e.g. Incident's Default view, Self-Service view, etc.).

Where do we find these names?

1. Type cache_inspect.do in the navigator.
2. Change the Type to Private.
   
3. The list of names are what you can use in the parameter.

If you cannot access cache_inspect.do, this may be due to an ACL denying access to that UI Page ( ).

There you have it. Instead of doing an all-or-nothing approach to the cache, you now can target which part to clear. This provides relief to your issue while minimizing the impact to system performance. So if you are planning on creating scheduled jobs to clear the cache (you know who you are, I've seen those questions!), at least target the part that you have identified (using troubleshooting) as being problematic.