Analyzing API Call Performance From Different Global Locations Based on cURL Metrics
Learn more about analyzing API call performance from different locations around the globe.
Join the DZone community and get the full member experience.Join For Free
My previous post presented “A Graphical View of API Performance Based on Call Location.” In that post, we analyzed the performance of a week of calls to the World Bank Countries API (which is served from Washington DC) from four different locations around the globe: Washington DC, USA; Oregon, USA; Ireland; and Tokyo, Japan. The API performance across the week showed remarkable consistency. Calls to the API from Washington DC had by far the best performance; calls from Ireland generally outperformed calls from Oregon, which generally outperformed calls from Tokyo. Here’s the data for the week (the Y-axis is logarithmic):
The timings for calls to APIs are broken down into components by cURL, “a command line tool and library for transferring data with URLs.” In addition to providing total performance timing (shown in the above plot), the API Science Performance Report API also provides individual cURL component timings. The cURL component timings are:
- Resolve Time: the time it takes to call and receive a reply from an Internet domain registry that translates a text URL into a numeric IP address
- Connect Time: the time it takes to initiate contact with the API server and receive a response indicating that a connection between the client and server has been established
- Processing Time: the combined time it takes for the client to send the request to the server, for the server to process the request, and for the server to indicate to the client that a response is ready to be transmitted
- Transfer Time: the time it takes for the server to transmit the response to the client
Additionally, you can check out my post What Do Curl Timings Mean? for more details on the cURL component timings.
I analyzed the cURL component timings to determine the factor that each component played in the total performance of the World Bank Countries API when called from the four global locations.
Here is the resolve time data from each location:
Here, we see that the performance time for attaining the IP address of the World Bank Countries API was lowest when the API is called from Washington DC, a bit higher from Ireland, and highest from Oregon and Tokyo. What does this mean? Internet URLs are resolved into numeric IP addresses by Domain Name Servers (DNS), which are located around the world. The time to resolve a URL will depend on the distance between the client and the nearest DNS, the speed of the Internet connection between the client and the DNS, and the speed by which the DNS can process a request. This graph implies that clients located in Washington DC and Ireland, in general, have access to quicker domain resolution than clients located in Oregon and Tokyo. The difference from best to worst is about 100 milliseconds.
Here is the connect time data for each location:
Here, there are very distinct differences with respect to calling location. Once the URL has been resolved into an IP address, a Washington DC client connects almost immediately with the World Bank server (which is also located in Washington DC). Meanwhile, it takes about 75 milliseconds for clients in Ireland and Oregon to connect, and about 160 milliseconds for a client in Tokyo to connect.
Here is the processing time data from each location:
Again, the processing time from a Washington DC client is fastest, followed by clients from Ireland and Oregon, and lastly Tokyo. To analyze this plot, we have to go back to the definition of “processing time.” The World Bank server surely doesn’t process requests from different locations at different speeds. The Processing Time cURL measure is the time between when the client begins to upload its request and the time when the server notifies the client that the response is about to be delivered. So, the differences in the graph above primarily reflect the time it takes for a request to be uploaded to the World Bank server from the various locations. For a Washington DC client, it’s very fast to upload a request to a Washington DC server. From farther away locations, the upload of the request takes more time (around 200 milliseconds more from Tokyo, for example).
Here is the transfer time data from each location:
Transfer time, somewhat remarkably, is about the same for all locations. Transfer time is the time between when the client recognizes that the server has indicated that it is about to send the response and the time when the full response is received. The response data for the request in this experiment is a very small number of bytes. For a request that required a very large number of response bytes, we’d probably see the same type of divergence the other plots illustrate, namely the farther away from the server the client is, the slower the transfer.
Adding It All Up
So, adding up all of the cURL component data by location, we get something like this for each client location calling the World Bank Countries API which is located in Washington DC (timings in milliseconds):
- Washington DC: Resolve 50; Connect 1; Processing 10; Transfer 0.2; Total 61
- Ireland: Resolve 80; Connect 70; Processing 100; Transfer 0.2; Total 250
- Oregon: Resolve 150; Connect 78; Processing 100; Transfer 0.2; Total 328
- Tokyo: Resolve 180; Connect 160; Processing 200; Transfer 0.2; Total 540
The “Total” values reflect the first chart in this post.
The distance between a client and an API server fundamentally affects the overall performance of calls to the API. If your product relies on calls to APIs located far across the globe from your data center, what your customers experience will be adversely affected. It is advisable to consider this impact when you design your product.
Published at DZone with permission of Kevin Farnham, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.