Search

Viewing Session Metrics

Overview

Once you’ve defined your Session Metrics, created a Group, and added your Definitions, you can collect Session Metrics through your Continuous or Load Tests. Session Metrics appear as radio buttons in Continuous Testing Results and Load Testing Results charts.

Note that charts only display metrics with the same unit (%, Ops/Sec, Bytes, etc.) simultaneously. This unit is set when you structure a Session Metric definition for an API request.

Continuous Testing

Below is a chart showing performance counters from a Group linked to the Test. For any Test, once the Session Metrics radio button is selected, a list of all associated Metrics will appear.

1.png

Metrics that were unable to collect data (e.g., incorrect query definition, incorrect authorization) will still appear on this list. To verify that Session Metrics work as expected, it is recommended to create a Test without any Actions. Assign your Session Metrics Group to the Test and run it once. Use the dashboard to confirm which definitions are accurate and which Metrics may need to have their definition double-checked.

In a Continuous Test, Session Metrics are aggregated on charts as follows:

  • Hourly view: by minute
  • Daily view: by hour
  • Weekly view: by hour
  • Monthly view: by hour

Using wider time periods enables trend analysis of performance counter data while minimizing the impact of outliers from isolated incidents or anomalies in the environment. For the analysis of environmental issues or anomalous behavior, use a shorter time period to visually highlight any deviation.

Tip: Drag your mouse across the chart to focus on the selected range.

Frame 885.png

Tips for Analysis

Every environment is different, and each organization has its own set of KPIs or thresholds used for observability, monitoring, and alerting. For analysis of particular scenarios or anomalies, consider a more targeted approach. Here are some general guidelines for analyzing your Continuous Testing Session Metrics:

  • Environments are different: Consider the context of your environment when analyzing Session Metrics. Factors like the business industry, the nature of its end-users, and the infrastructure that they rely on can lead to different conclusions based on the Session Metrics you collect.
    • Is the test device a shared resource (e.g., Multi-Session or terminal server), or is it a dedicated device like VDI or a physical endpoint?
    • Are there major shift changes or user logon patterns that could impact performance?
    • Are there scheduled tasks, scans, or background processes that could influence performance at certain times?
  • Environments change: Updates to applications or the OS and other environmental changes can impact performance. Use the context of your organization’s environment to correlate changes in the Metrics you collect. CPU and Memory metrics (collected by default) are useful for understanding the impacts of major changes.
    • Have there been recent updates to the OS or applications?
    • Were there changes to the network, infrastructure, device, or its resource allocation?
    • Did security policies, antivirus configurations, or other system settings change?
  • Application behavior: Certain workflows may involve resource-intensive operations, leading to increased system utilization. Identifying correlations between specific actions and performance metrics can provide valuable insights. You can track process-specific resource utilization with Session Metrics for your key Line of Business apps, AV solutions, or other security applications.
    • Are there application executions that consistently lead to higher resource consumption?
    • Are there deviations at specific steps, or is resource utilization sustained throughout the workflow?

Tip: If there are potential optimizations to configure, use a Performance Test to A/B test them.

Load Testing

Unlike Continuous Testing, Session Metrics collected during Load Tests are meant to be analyzed in relation to the Test’s active session count. Depending on the environment and the number of users configured for the Test, there may be different implications.

Login Enterprise supports both persistent and non-persistent virtual desktops across Client and Server OS, including Windows 11 Multi-Session.

For multi-user Load Tests, Login Enterprise can collect Session Metrics from a configurable number of sessions.

  • In Multi-Session or Server OS environments, collecting metrics from a single session helps control data volume, as each user will return identical performance counters from the same OS.
  • In Client OS environments, such as VDI or physical endpoints, each Session’s Metrics reflect the unique performance of its respective VM or device.

2.png

Tips for Analysis

Load Testing analysis is different from Continuous Testing. Many customers use Load Tests to performance-test their latest OS images. Unlike Continuous Tests, where you’re monitoring and alerting, Load Tests are more focused on identifying issues and preventing them.

Here are some general guidelines for analyzing your Load Testing Session Metrics:

  • System behavior under load: Systems behave differently under high user concurrency. Identifying how performance changes under different load conditions can reveal limitations and highlight bottlenecks.
    • Does the number of users correlate strongly with any Session Metrics being collected?
    • Is the system compute-bound, memory-constrained, or storage-limited? Is it network-dependent?
  • A/B Testing: When large-scale changes are made (e.g., Gold Image updates, endpoint AV deployments), performance tests can highlight benefits and weaknesses through A/B Testing.
    • In a controlled comparison, are there major changes to resource consumption between changes?
    • Where are the changes likely to have the biggest impact: Compute? Memory? Storage? Network?

Frame 886.png

Additional resources