How to debug and analyze API spikes

In this article I will describe the process of analysis one can apply to understand where the calls and subsequent spikes can originate from. The key element for determining what contributes to a larger-than-expected number of API calls is having a controlled environment. That is an environment where you can correlate users’ actions to the data you see in Backendless API analytics.

For a live application where users log in and perform various app functions, you will see aggregated data showing how many calls of different types were performed by all users over a period of time. Unfortunately, in that type of setup, extracting what the individual calls are and which APIs each user has contributed to the total numbers would be a very hard task. As a result, the hunt for spikes and areas to optimize will not be productive. The primary reason is that you do not know what users did, what pages they visited, and what navigation flows they executed. The environment is not controlled.

The simplest approach for creating a controlled environment is to clone your live Backendless app. This way you get a replica that is isolated from the users. When you use the cloned app, you know exactly what pages you navigated through and what operational workflows you executed. As a result, when you look at the analytics, you will see the API numbers that will be generated from a single user’s actions. At that point, the analysis becomes a repetitive flow consisting of:

  1. Performing a single-user function (i.e. going through the registration page or navigating to the main app screen or performing a specific function in the app, etc)
  2. Checking on the API CALLS screen to see what API calls were recorded by the system.
  3. Determining if the numbers are greater than anticipated and if so, checking the actual logic that corresponds to the actions performed in step 1.
  4. Making fixes in the logic and then re-running this process right from step 1 until the numbers look good.

Keep in mind that whatever the numbers you see are for a single user. When you have multiple users (in your live app), the numbers would need to be multiplied by the number of active users.

When you are done with the fixes and optimizations, they should be deployed back to the live app. The changes in UI can be deployed by creating an archive (zip) of the UI container and copying it to the live app’s Files storage. If the changes were done in the codeless API services, they can be deployed to the live app using the Sync Changes feature in Backendless Console.

I hope this is helpful and gives you an idea of how to proceed with further optimizations of your apps.