Optimize Rest Call for integration

[cesargonzalez]

We are trying to make a Rest Call to NetApp OCI with JSON that provide us with data on volumes and their relationships to storages and hosts. We came across that the rest call will retrieve only 1 volume and theirs relationships at a time. We don't have a call that provides us with all the volumes in one call.

We are performing a loop that execute a one call at a time and gets the response and move it into a local table in ServiceNow. It is taking a lot of time to complete the cycle since we are trying to gather 23,000 volume records on a weekly basis.

Note: We are not parsing the response yet, just pushing the response into a temporary table in a long string field

Result: The time to execute 1000 calls is 4 hours and 13 minutes. Number of calls made: 1000 from 23,026

Start: Sep-15-2015 11:13:21 PM

End: Sep-16-2015 03:23:25 AM

Question:

1. How can we make this call efficient, do you have any solutions on or if you can do anything different from what we are doing?
2. Is there a way to find out the stash around the time consume to make the call and gather the response, how do we gather this measurement?

[coryseering]

Hi Cesar,

The longest time spent will probably be in building the TCP connections, transmitting data, waiting for a response, then getting that data. Those are all pieces you don't really have control over- it just takes time to build the connection, authenticate, and download. hopefully the authentication happens only once at the start of the process, and you then get a token you can use on subsequent requests to prevent you from having to continuously authenticate with each request. If you aren't, I'd look into that- see if the API sends one back (perhaps int he from of a cookie) which you can re-use.

The other thing to do is parallelize this. If you're kicking it off from a scheduled job, split the workload in 2, or 4, or 10 pieces, and kick them off simultaneously. So long as you have a way to split up the requests so you don't duplicate work, you can speed it up quite a bit by doing it in parallel. There is a limit to the number of simultaneous outbound HTTP requests the instance can make, so don't try to do 100 at the same time, but 5 or 10 shouldn't be a problem.

I'm not sure how figuring out the time before and after the request is made is helpful, but you can always create a new GlideDateTime object and call getNumericValue on it to get the current date/time down to the millisecond. Do that before and after the block you care about, then subtract the before from the after, and you have the number of milliseconds that block took to execute. Again, I don't know how helpful that is, given the time is probably most spent on the HTTPS connections rather than in processing. I guess it couldn't hurt to verify that though.

[silas1]

Hi Cesar, I would second Cory's recommendations to parallelize the calls. Try to determine how long one request takes and then do the (rough) math to figure out based on the amount of time you want the work to complete in how many concurrent calls you might have to make. Keep in mind that the more active callers into the 3rd party API, the slower the 3rd party API might be to respond to each caller.

There is actually very little overhead in making a REST call from the instance. We use a connection manager that caches HTTP connections for re-use, so the cost of establishing the connection is only paid once. The primary contributing factors in determining how fast or slow the calls can happen are:

• Network latency between the instance and the 3rd party
• Time the 3rd party spends responding to a request (i.e. time the SN client spends waiting for the response)
• Time spent in the SN script *processing* the response. (i.e., what do you do in each loop iteration -- are you waiting to write the data somewhere before you make the next call to the 3rd party)

From the SN side, in addition to parallelizing the requests you might look into making the requests asynchronously as well using RESTMessageV2.executeAsync.

[cesargonzalez]

Ok, thank you. I have tried the parallel calls in a workflow and it didn't reduce too much but there was some improvement