Identify Remote Display Latency (Troubleshoot Remote Display)

The Troubleshoot Remote Display dashboard highlights the delays to performance caused by remote display latency in virtualized environments, showing the delays in different locations or data centers. Use this dashboard to isolate the infrastructure issues which are causing the slowdowns in virtual deployments.

The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways). Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond.

Remote display latency is the time in both directions from the front line user to the virtual server

For example, if a user types the character 'g' in a text editor which runs on a virtual application server, when the remote session sends this action to the virtual server, the remote display latency is the lag time between typing 'g' to seeing the 'g' on the screen.

In many cases where high remote display latency is an issue, the client side and the server side might be far away from each other, for example on different continents. If you have users in Europe who use remote desktops and complain about slowness, and their virtual machines are in Hong Kong, consider investing in a data center or hypervisor in Europe.

This dashboard supports virtual application servers (like Citrix XenApp), virtual desktop servers (like VMWare vSphere), and remote desktop connections like (Microsoft RDC).

The Troubleshoot Remote Display dashboard

A baseline is a threshold to which a measured time is compared to decide if it is as expected, or if it is too slow. Aternity automatically defines two baselines around the expected response time: a minor baseline which constitutes a minor departure from the expected performance, and a major baseline which constitutes a major departure from the expected response time. The latency is compared to its own baseline and is given its a status of normal, minor or major depending on recent baselines of expected delays due to latency. This is separate from the activity response time, which is also given a status depending on its own baselines.

Note

When you view an activity's response time in a VDI deployment, there are two separate times you must add: the regular application's response time on the VDI server itself (made up of the client time, server time and network time) and then add the remote display latency between the VDI server and the front line end user of the virtual desktop.

For any given activity response, if we assume that there is only one round trip from the client to the VDI server for the activity and its response (which depends on the architecture of the application deployed in VDI), the total response time of an activity would be:

VDI response time = (2 x remote display latency) + activity response time

Typically, however, the virtualization platform would use more than one round trip to the virtual application server or VDI server for each activity, so it would be many more than 2 x remote display latency.

Effective response time of a VDI end user

Procedure

  1. Step 1 Open a browser and log in to Aternity.
  2. Step 2 Access the dashboard by typing its name in the search box in the top bar.

    Alternatively, access the Remote Display dashboard by selecting first Main Menu > Troubleshoot > Virtual Desktop.

    Accessing Troubleshoot Virtual Desktop

    Select the Remote display latency option in the pop-up window.

    Select to troubleshoot the remote display latency
  3. Step 3 See the clients with remote display latency problems which need your attention, their location, and the servers or virtual machines they connect to.
    Check where the latency issues in your company are concentrated
    Field Description
    Client Locations

    Check if the client devices which have the highest percentage of long latency time are concentrated in a certain location.

    Client Devices

    Check which users and client devices have the highest percentage of long latency time.

    Cities

    Check if the problem impacts all end users working from a specific location (also collated by Cities, States, Countries, and Regions). You can also view this information on a map in the Geographies - Map section.

    For example, if performance is slow only for users in the office in North London (a business location), check the networking infrastructure of that specific site. But if the problem affects all the offices in London (under Cities), you can check the wider infrastructure which is common to all those locations, like a data center.

    Servers/Virtual Desktops

    Check if the problem occurs for all users who connect to specific servers or virtual machine.

    Data Center Locations

    Data Center Locations in Aternity lists the locations of any virtual application servers (like Citrix XenApp) and VDI hypervisors (like in VMWare vSphere) which run the application. If the application is deployed both locally and virtually, one of the locations displays as Local.

    Latency

    Presents the average latency time (in seconds) during the timeframe of the dashboard, for the criteria selected in the dashboard's sections.

    Normal, Minor, Major

    Presents the percentage of latency times which have a status of normal, minor, major. Your goal is to have all the latency measurements in the normal category.

    All the sections in the dashboard, except for the Trends section, display the average latency time and the percentage of latency times with each status, organized by different criteria. The latency times which need your immediate attention (the highest percentage with a status of major) appear on the top, so that you can easily see them.

    Field Description
    Major (orange)

    When an activity has a status of Major (colored orange ), it indicates that this activity response time requires attention, as it was significantly slower (a major departure or deviation) from the expected baseline performance (major activity threshold) of this activity.

    Minor (yellow)

    When an activity has a status of Minor (colored yellow ), it indicates that this activity response time is slightly slower (a minor departure or deviation) from the defined baseline performance (minor activity threshold) of this activity.

    Normal (green)

    Normal refers to the status of an activity when its performance is good, since its activity response time is within the defined baseline performance of this activity. It is usually colored green .

  4. Step 4 Use the trends section to verify when the latency issues started and for how long they continued.
    See the latency changes over the timeframe of the dashboard

    In case the selected timeframe does not include the beginning of the latency issues, use the Timeframe drop-down menu to extend the time period. Hover over the graph to see the exact time of the measurement and the average latency time. Look at the recent statuses of latency over time, to see if it is improving or worsening.

    If you want to focus on the times with the worst latency, select a place of interest on the graph. A second graph opens below and displays a zoom-in one hour after the time you selected on the upper graph, so you can pinpoint the changes. If you choose, for example, 7am, the lower graph displays the average latency between 7am and 8am on the same day.

    Zoom on the latency peaks
    Field Description
    Time

    Presents the day and hour of the measurement.

    Score

    Presents the score for the statuses of all the latency times calculated by condensing all the latency statuses (normal, minor, major) into a single value.

    Status

    Presents the status associated with the latency score. A poor status is a call for your immediate attention.

  5. Step 5 View the latency time and the percentage of latency measurements which are slower than normal and drill down to other dashboards to find out details about the possible causes of the high latency.

    Hover over the orange, yellow or green section in any of the dashboard areas and view the latency details in the pop-up window, to decide if you need to take urgent measures. If you know that your target latency is, for example, 0.05s and your average latency of the users in the United Kingdom has been 0.714s for a week, you have to take action.

    Drill down to other dashboards to troubleshoot further

    You can investigate further on the possible reasons why latency might be unusually long, by drilling down to any of the following dashboards:

    • The SLA dashboard, to view the occurrences when the performance is slower than your service level agreement (SLA) thresholds. For example, drill down to the SLA dashboard from the London House field in the Client Location section. You see the applications which have the worst response times and the activities which exceed the target threshold. From there, you can drill down to the Troubleshoot Activity dashboard and try to find a correlation between the latency time and the traffic volume, or with the client, server or network times.

    • The Activity Resource Analysis dashboard, to see the effects of an activity directly on the resources of the device.

    • The Troubleshoot Boot dashboard, to see the performance of different devices in terms of boot times.

    • The Device Health dashboard, to troubleshoot hardware, system, and application issues. For example, for WKS_server_5 you can see if there has been a sudden change in the number of health events recently reported to the system, application and system crashes, software update failures, and so on.

    • The Desktop Reliability dashboard, to view the stability of both client and server devices.
    • The Monitor User Experience dashboard, to see the recent log of events performed on this device.

  6. Step 6 Troubleshoot your latency problems by finding the common element where the performance problems are concentrated, by selecting that element and viewing other sections of the dashboard.
    Isolate the view of your dashboard to the longest latency times

    To troubleshoot, you can investigate problems with virtual servers, or possible common problems on the front end client.

    To troubleshoot the remote display latency you can investigate the server side by selecting, for example, the data center location which has the highest percentage of latency times with a status of major. The dashboard displays only the servers, devices, and trends concerning that location, making it easy for you to see the possible correlations. You can then select the server which has the worst latency status at that data center and view all the client devices remotely connected to that server. Verify the common attributes between those devices. Then, from the Client Devices section you can drill down to any of the dashboards which offer in-depth information regarding the performance of those devices (Monitor User or Device, Desktop Health, and so on) to continue your investigation into their hardware and software issues.

    Alternatively, select the client location with the highest percentage of long latency times and then investigate the users connected from that location and to which servers or data centers.

    Extend the dashboard timeframe in the Timeframe drop-down menu to find out when the longer latency began.

  7. Step 7 Limit the display to virtual application servers or virtual desktops and choose to display all or specific protocols in the top menu of the dashboard.
    Limit the view of the dashboard
    Field Description
    Timeframe

    Choose the start time of the data displayed in this dashboard.

    You can access data in this dashboard (retention) going back up to seven days. This dashboard's data refreshes every hour.
    Device Type

    Select one of the following:

    • Virtual App Servers offer multiple users access to a single setup of an application, for example, with Citrix XenApp.

    • Virtual Desktops offer the ability to run an application within a VDI environment, which is a virtual instance of the entire desktop operating system (usually Windows).

    Protocol

    Displays the remote display protocol:

    • ICA, the protocol used by Citrix XenApp.

    • RDP, the protocol used by Microsoft products like Remote Desktop Connection. It is also increasingly being adopted by newer versions of Citrix XenApp.

    • PCoIP, the protocol used by VMWare's VDI systems.

    Status

    Choose whether to display only the activities which are exceeding SLA thresholds. Select one of the following:

    • Exclude Normal displays only activities which exceed their SLA thresholds.

    • All does not exclude data.