Performing URL-Based Load Testing with Azure Load Testing

Load testing is a crucial practice for enterprise APIs to ensure optimal performance under varying traffic conditions. Azure Load Testing, a fully managed service, helps evaluate the performance, scalability, and capacity of your applications, particularly APIs. It enables you to simulate high-scale traffic, uncover performance bottlenecks, and optimize system resilience.

Azure Load Testing allows you to create sophisticated load tests using tools like Apache JMeter while also offering the flexibility to perform URL-based load testing without the need for external tools.

In this article, I will demonstrate how to perform URL-based load testing for an API exposed through the Azure API Management service using Azure Load Testing. 

Configuration of Load Test

Go to your Azure Load Testing instance, click on "Test", and then select "Create a URL-based test" to begin setting up your load test.

Specify Test details

In Test plan section click on Add request

Enter the details of your API, including the endpoint URL and request method. Since my API retrieves Star Wars characters by their ID, I configured the id parameter as a variable, allowing the test to simulate different requests dynamically.

Next, I created a CSV file containing multiple rows with different id values to be injected into the id parameter of my API. To simulate an error scenario, I intentionally included an id value of 1500, which does not exist in my API. This helps evaluate how the system handles unexpected inputs and errors under load.

In the Load section, I configured key parameters such as the number of engine instances, concurrent users, and test duration. Since this test is for demonstration purposes only, I selected the minimum values to keep the load minimal while still assessing the API’s response behavior.

For monitoring purposes, I added relevant resources to my load test, allowing me to analyze their performance directly from the load test dashboard. Since my API Management instance and Application Insights are crucial for this test, I included them to gain deeper insights into API performance, request handling, and potential bottlenecks.

Next, I navigated to the Test Criteria section, where I defined success and failure conditions based on key performance metrics. I set the test to fail if:

• The 90th percentile response time exceeds 1000ms
• The error percentage is greater than 5%

Execution of Load Test

With the Load Test configuration complete, it's time to execute the test and analyze the results.

Here are the results I received from the load test.

I got following key statistics

• Load
• Duration
• Response time
• Error percentage
• Throughput

The Load Test has failed because it didn’t meet the test criteria I set. Specifically, the error percentage surpassed the 5% limit.

Analysis of error requests using related resources

Since we've integrated Application Insights as a related resource, we can dive deeper into the analysis. Let's focus on the Failed Requests chart, which will provide insights into the specific requests that failed during the load test, helping us identify potential issues or bottlenecks in the API.

To further investigate, click on the Failed Requests chart in Application Insights, then select Drill into Logs and navigate to Failures.

The failure dashboard reveals that there were 9 "Not Found" (404) errors during the load test.

It tells me that there are no Star Wars characters with 1500 as the id

Debugging API Startup Errors Using Kudu in Azure App Service

Recently, I had to debug a .NET API hosted in an Azure Web App. The API failed to bootstrap and returned only a generic error message, which provided little insight into the issue.

Unfortunately, the application lacked Application Insights integration, making the troubleshooting process even more challenging.

Following is the approach I took.

I navigated to the Development Tools section of the App Service and accessed Advanced Tools to investigate further.

From there, I navigated to Kudu and accessed the Debug Console to further analyze the issue.

Navigate to wwwroot location and locate the particular exe of your API

I executed the .exe file directly in the Debug Console to capture the specific error message and identify the root cause of the issue.

By running the .exe file, I was able to see the detailed error message, which revealed that a required configuration item was missing for the application.

Configuring Postman to Retrieve an OAuth 2.0 Token from Entra ID for Calling an API via APIM

This article is the second part of a two-part series. Below are the different parts of this article series.

• Securing Backend API Using OAuth with Entra ID and Azure API Management
• Configuring Postman to retrieve an OAuth 2.0 token from Entra ID for calling an API via APIM 

In this article, I will guide you through configuring your Postman client to retrieve an access token from Entra ID, enabling you to call an API exposed via APIM.

For better organization, I have grouped related APIs into a collection.

Navigate to Authorization section and provide following details

You can obtain most of the required details from your client App Registration. These parameters are readily available in the Endpoints view of your client application. We covered how to create and configure a client App Registration in our previous blog post.

Following are some important parameters

#Auth URL
OAuth 2.0 authorization endpoint (v2) in the Endpoints view of your client app registration

#Access Token URL
OAuth 2.0 token endpoint (v2) in the Endpoints view of your client app registration

#Client ID
Client ID of your client app registration

#Client Secret
#Client ID
Client secret you generated within your client app registration

#Callback URL
Redirect URL from the Authentication section (Shown in below diagram)

That completes the configuration. You can now click the Get New Access Token button to interactively retrieve an access token.

Next, ensure that your API is configured to retrieve the token from the parent as shown below.

Then, you can successfully retrieve response with valid access token