Timing-Out Slow-Performing External API Requests

API performance varies depending on many variables, including the response of the Internet (for example, resolve time and transfer time) and the timing for work that occurs on the remote server (connect time and processing time). My last post illustrated that calls to the World Bank Countries API sometimes exhibit abnormally slow performance.

Unpredictable, though occasional, slow performance when you call an external API will make your own product appear to exhibit poor performance. It may not matter if the delay is relatively small (a second or two). But my monitoring of the World Bank Countries API has shown several instances where a single call to the API took up to 10 seconds to complete. No customer is going to want to wait 10 seconds (or a multiple of this if the API must be called multiple times) to see a response on their device.

The API Science platform provides a “Max Response Time (ms)” validation that lets you specify the maximum amount of time allowed for receiving the response to a request. If the response is not received before the specified time expires, the call is considered to have failed.

We can test this using the World Bank BRIC monitor. Clicking “Edit” (or the pencil icon on the Dashboard) brings up the monitor’s edit page. Click “Show Settings” to see the details:


The “Validations” pull-down lets you select the type of validation you’d like to perform:

  • Response Code
  • Regex
  • Validate JSON
  • JavaScript
  • Max Response Time (ms)

Select “Max Response Time (ms)” and enter a millisecond value:


Clicking “Test Now” runs the test, which in this case produced a valid result:


The Call Summary shows that the total time for completing this request was 57.68 msec. If we modify the “Max Response Time” value to a very low value (for example, 10 msec), then the monitor run should fail. This is indeed what happens:


The server responded to the request and returned its result 26.15 msec after the request was initiated. But, since we defined a 10 msec maximum response time, and the actual response time exceeded this, the test fails.

Flagging Abnormally-Slow World Bank Countries API Calls

World Bank BRIC monitor tests typically complete in less than a second. However, there are occasional aberrations where the test takes up to 10 seconds to complete. Rather than have users wait 10 seconds after a button click, lets assume we want to get whatever BRIC data is quickly available, but tell the user “data is not currently available” for any request that takes too long. This would ensure that your user always receives a prompt response.

The table below lists the timings for a typical WB-BRIC monitor call, along with the millisecond timings for a call that took an abnormally long time (1796 msec) to complete:

Monitor Step Typical Long
1. Brazil 281 285
2. Russia 177 471
3. India 175 541
4. China 173 503

We see that, under normal conditions, the calls for an individual country occupy less than 200 msec (the timing for Brazil is affected by a longer resolve time, since that request is executed first by the monitor).

Assume we don’t want our users to have to wait more than twice as long as normal to receive their result. We can configure our World Bank BRIC monitor to validate that each monitor step must complete within 350 msec. If any of the monitor steps takes more than 350 msec to complete, that test will be flagged as failed, due to the maximum response time criterion.

I’ve configured all four steps in the BRIC monitor to validate that the Max Response Time is 350 msec. If any step fails this test, then the entire monitor run fails.


I’ll let the updated monitor run now, expecting to see any excessively slow performance by the World Bank Countries API flagged by the new validation settings. This will let me formulate a plan for addressing World Bank API anomalies in the applications I provide to customers.

–Kevin Farnham