One of the key metrics that Azure Application Insights tracks is the overall duration load time of components in an application. This metric measures the time it takes for a page or API request to be fully loaded and processed. The load time can be affected by a variety of factors, including network latency, server and client side processing time.
Having an overview of the overall duration load time is critical for administrators and applications owner. This can help them to:
- Identify performance bottlenecks and prioritize areas of the application to optimize. If certain pages or API requests have a consistently slower load time than others, admins can investigate the causes and take actions to improve the performance of those areas.
- Monitor the total duration load time to ensure that the application is meeting your users' expectations for speed and responsiveness. Slow load times can result in frustrated users and decreased engagement. By monitoring load times and making improvements as needed, you can keep users engaged with using your application.
Thus, the total duration load time of an operation is an important part of performance monitoring for any implementation, the Azure Application Insights integration with Dataverse Analyze model-driven apps and Dataverse telemetry with Application Insights - Power Platform | Microsoft Learn provides a powerful set of information & tools to help you track and analyse this metric. Currently, the duration of an end-to-end operation is not returned as a property. In order to get this value, a Kusto query (Kusto Query Language (KQL) overview- Azure Data Explorer | Microsoft Learn) can be used to get the total duration of the overall operation by doing the SUM of all durations of requests, dependencies and pages view per operation which will help on getting the information and how this evolve over time.
This query can be adjusted to get the overall duration of load for a particular user, user session or operation, the metadata of the nature of the query (form load, view load,..) are not returned in the response, however, this can be identified based on background operations.
let results =
(requests
| extend endtime = datetime_add('Millisecond', toint(duration) ,timestamp), operation_Id
| summarize startTime = min(timestamp), endTime = max(endtime) by operation_Id)
|union
(dependencies
| extend endtime = datetime_add('Millisecond', toint(duration) ,timestamp), operation_Id
| summarize startTime = min(timestamp), endTime = max(endtime) by operation_Id)
,
(pageViews
| extend endtime = datetime_add('Millisecond', toint(duration) ,timestamp), operation_Id
| summarize startTime = min(timestamp), endTime = max(endtime) by operation_Id);
results
| summarize globalStartTime = min(startTime), globalEndTime = max (endTime) by operation_Id
| extend totalOperationDuration = datetime_diff('Millisecond',globalEndTime , globalStartTime)
The results of the query appear as following with:
- operation_Id: Corresponds to the operation ID, it’s formatted as {sessionId}_{activityId}
- globalStartTime: Corresponds to the start time of the operation
- globalEndTime: Corresponds to the end time of the operation
- totalOperationDuration: Corresponds to the total duration of the operation in milliseconds
In summary, if there are performance problems, the administrators can include filters based on userId or activityId. The query mentioned above takes into account the concurrent calls made to avoid counting them multiple times.
