Multiple REST Calls at the same time?

[Oliver D_sereck]

I have a customer that is facing an interesting issue. They have programmed their own system that stores multiple types of data (users, locations, customers, contracts etc) and each piece of data has its own API that we can call using REST. This is really great, but they want the data in ServiceNow to be as actual as possible, so we have the following situation:

4x Scheduled Jobs running every minute, calling 4 different Functions in a Script Include. Each function calls a different REST Web Service API. Each call delivers a few parameters, one being to only retrieve the last 2 minutes of updated data (only a few records, normally 0 though).

Now when these Jobs are running, the instance slows down to a grind. When the REST call happens, page loading shoots up to 10-15 seconds (instead of the normal few milliseconds). When switching off the jobs, the instance runs fine. The instance has 4 semaphores and 8 schedule workers. Even if I disable all but 1 scheduled job, this call still hangs the system. The scheduled job "run as" is empty, so the system is actually executing the jobs (I also tried using a dummy admin user).

Sure, the script include is last updated by my user, but I am not the only one that experiences the slow down when the call happens. How does ServiceNow actually handle the REST call? Is there a different way to call the webservice async (use a business rule)? Having up-to-date data is a must, so increasing the job time to 5+ minutes is not possible. REST is also the only method, so no SOAP. I am already in the process of increasing the semaphores but I doubt this will help. It seems ServiceNow is doing a REST call more in the frontend than the backend...which isnt really possible.

Ideas?

[Oliver D_sereck · Accepted solution]

I found the issue. I thought I would be smart and set a property at the start and at the end of the function (and ofcourse if something breaks/no value returned etc.) to make sure 2 jobs dont run at the same time. Well...setProperty is a horribly slow function and should not be used for such work. I will be trying a normal gliderecord update instead.

[Dan_Berglin]

setProperty is probably slow if the property isn't configured to ignore cache (property changes defaults to clearing the cache = same as cache.do = slow and affects the whole instance )