Evaluating the Performance of Critical APIs Using API Science’s Data Analysis Tools

The API Science API monitoring platform provides an array of data analysis tools for viewing the performance of internal or external APIs that are critical to your product, from the top level (represented by our weekly summary report) down to the fine-grain details of the results from a single test run of an individual monitor. You need both viewpoints. The high-level view provides the best indication of the general reliability your customers are experiencing as they use your product, while the low-level view enables you to analyze why some of your customers may have experienced apparent outages of your service, or why all of your customers experienced an actual temporary outage.

If a week goes by and the APIs you monitor experienced zero outages, then your customers successfully received your product all week long (a very good thing!). However, if there were outages at any point between a customer’s click of a button and an API call that’s required to deliver the information that button click requests, then your customer experiences an outage of your product (even if the outage was from a third-party API, not your own API). When outages occur, you need to take action. Here, the API Science detailed analysis tools can be of help.

In this post, I’ll start with the high level, and proceed down to the low-level detailed displays that you’d want to examine in order to address specific customer inquiries (for example, the May 13 Washington DC World Bank Countries API anomaly that I wrote about in my last post).

Weekly API Science Report

The “Weekly API Science Report” is an email sent to your registered email account. It provides a summary of uptime, performance, and checks that occurred over the past week. When this report looks as great as my most recent report did, your product is likely performing perfectly:

api-science-weekly-report

API Dashboard

Your API Dashboard is your next level of detail on the performance of the APIs you monitor. This provides the current status, the latest performance and uptime mini-graphs, and the last time the monitor was run. In my own case right now, the results are perfect; but you certainly can’t count on that always being the case.

20160523_dashboard

Looking at that image, doesn’t “br Washington DC” stand out? What is that high peak to the right in the Performance plot? Let’s investigate.

Individual Monitor Summary

Clicking on “br Washington DC” brings me to the monitor’s summary page. The upper portion of this page displays basic information about the monitor and a plot of results of the last 10 monitor runs:

20160523_br_dc_summary_top

Below the plot there are tables listing the information for recent checks and uptime history:

 

20160523_br_dc_summary_bottom

Clicking “See all Checks” lets us scroll through the historical API checks. When we do this, we notice that, indeed, sometimes our test of the World Bank Countries API takes extraordinarily longer than the 78 msec mean performance displayed on the dashboard. For example, the test performed at 13:20 on May 23 took 9460 msec to complete! 9.46 seconds…

20160523_br_dc_summary_allchecks

API Check Details

Clicking on the “05/23/16 13:20” timestamp brings up the details of that particular API check:

20160523-br-dc-check-detail

Here we see something rather ominous. In my last post (“API Performance Outliers Based on Location”), the outlier API check that took 797 msec was caused entirely by a slow resolve time. That is, something happened with the Washington, DC Internet infrastructure at that particular time.

In this case, however, we resolved and connected in less than 15 msec; but for the next 9.44556 seconds the World Bank’s data center was processing our request! That’s a problem for your customers if they clicked a button that depends on this API call.

Conclusion

The World Bank Countries API, when accessed from our Washington, DC data center, has erratic performance — sufficiently erratic to affect the experience of your customers (how many people wait 10 seconds for a response to a button click?). But you wouldn’t know about this if you didn’t have the API Science analytics that let you see what happens with this API when it’s called from Washington, DC. It’s much better to know this in advance, so you can message your customers about the issue, rather than have them inform you that you’ve got a problem. They didn’t buy your product under the assumption that they’d become your Quality Assurance team…

In my next post, I’ll cover what’s available when you click on the API Science “Reports” tab.

 

One thought on “Evaluating the Performance of Critical APIs Using API Science’s Data Analysis Tools

Comments are closed.