Some weeks ago, I created API monitors that call the World Bank’s Countries API from four different locations: Ireland, Oregon (U.S. West Coast), Tokyo, and Washington, D.C. (U.S. East Coast). All four monitors request the World Bank information for Brazil.
Here’s a recent view of my API Science Dashboard for these monitors:
Each monitor is requesting and receiving the exact same information from the Countries API. Uptime has been 100% over the past 24 hours for all of the monitors. Yet, the performance differs significantly, and with general consistency, depending on the location from which the API was called.
What causes these differences in performance?
In a recent post (What Do Curl Timings Mean?), I described the four major operations that are involved in obtaining information from an API, and how curl (an application for transferring data with URL syntax, used by API Science and many others) measures these operations as the API request proceeds. Briefly, these operations are:
- Resolve Time: the amount of time it takes for a Domain Name System (DNS) “resolver” to convert the alphanumeric URL into a numeric Internet Protocol (IP) address and return that address to curl
- Connect Time: the amount of time it takes to communicate with the API server, request a “connection,” and receive a handshake signal from the server indicating that a TCP connection (a “socket”) has been established
- Processing Time: the time it takes to convey the request text to the server, plus the time it takes for the server to process the request, create the response text, and signal that the first byte of the response is about to be delivered
- Transfer Time: the time it takes for the server to deliver the entire response stream to the curl client
Clicking the links for each API monitor on the Dashboard page brings up the summary page for each monitor. Let’s look at these in order of worst-to-best recent performance.
Calling the World Bank’s Countries API from Tokyo, Japan consistently takes longer than calling it from the other locations. Why? Here’s the Tokyo monitor’s summary plot:
Looking at this plot, we see that the connect time (~150 milliseconds) and processing time (~160 msec) are very consistent, and that transfer time is too miniscule to even be visible on the plot. The variance in performance is due entirely to resolve time. For whatever reason, there is enormous variation in the time it takes for the DNS to resolve the World Bank’s Countries API URL from Tokyo (from 22 msec to 393 msec in this example).
How does this compare to when the Countries API is called from Oregon, which has the second worst performance? Here’s the Oregon summary plot:
Here, the pattern is similar in the fact that connect time and processing time vary little, transfer time is very small, and the variations in total time are primarily due to variations in resolve time. However, all classes of timings are lower when the Countries API is called from Oregon than when it’s called from Tokyo (for example, connect time is about 80 msec from Oregon, versus ~150 msec from Tokyo). Perhaps surprisingly, even processing time is faster when the API is called from Oregon (~90 msec) than when it’s called from Tokyo (~160 msec).
Now let’s look at the Ireland summary page:
Again, we see the familiar pattern: all variation in total time is explained primarily by variations in resolve time. Connect time and processing time when the Countries API is called from Ireland is about the same as when the API is called from Oregon. The total performance is faster from Ireland because the resolve time from Ireland is usually briefer than the resolve time from Oregon.
Now let’s look at the Washington, D.C. performance:
Calling the World Bank’s Countries API from Washington, D.C. provides by far the best performance (the tall column on the right is an outlier). It happens that the World Bank is located in Washington, D.C., and the curl timing evidence is that their Countries API server is also located there. While the outlier in this plot makes it difficult to view the timing numerics of a typical call to the Countries API from Washington, the API Science Performance Report, which lists the timings by category, shows the following typical curl timings for D.C. calls:
- Resolve Time: 30 msec
- Connect Time: 1 msec
- Processing Time: 15 msec
- Transfer Time: 0.1 msec
- The global location from which an API is called has a large impact on performance.
- Variation in performance when an API is called from a particular location is due primarily to variation in resolve time.