Guidelines for Slow Application

Scenario

One or more end users report experiencing slower-than-expected access to a specific application, a fileserver.

Prerequisites

To encounter this scenario, the following prerequisites must be met:

• Zones have been configured to reflect the customer’s network topology.
• The application, Samba_CIFS, has been identified.
• The traffic to the fileserver is mirrored to one of the probe's listening interfaces.

Analyzing the Issue

An ideal starting point would be to get a global view of the application's performance. By displaying the Application Dashboard for a relevant period of time, a peak in SRT from 6 to 18:15 can be observed. When breaking down by zone, it can be concluded that only one zone has been impacted. Clicking on that zone will display the client zone’s application dashboard.

From this, it can be concluded that only a single client (user) was impacted. The issue was clearly caused by a slow server response, potentially due to an application issue or a particularly complex request that was challenging to process.

Examine the Application Dashboard for a relevant timeframe in the past, such as the last 48 hours. The upper section of this dashboard displays the End User Response Time (EURT) trends over time for the fileserver.

• It's been observed that the quality of user experience, when accessing this application, significantly declined yesterday afternoon.
• It can be identified that this was caused by a degradation in RTT (Round Trip Time, an indicator of network latency) rather than the Server Response Time (SRT) or the Data Transfer Time (DTT).

From this graph, it can be concluded that the server and the application are unlikely related to the slowdown. Examining the two bar charts, which display the breakdown by server and by client zone respectively, allows the following conclusions to be drawn:

• This application is distributed by only one server (192.168.20.9).
• The EURT vary in large proportion between client zones, mainly because of RTT.
• VLAN_Sales experiences significantly slower access to the application compared to VLAN_R&D, mainly due to higher network latency.

To confirm the initial conclusions, click on the peak of EURT in the upper graph. Narrowing the observation period helps provide a clearer understanding of what happened at that specific time.

This confirms the following conclusions: RTT went up for (only) VLAN_Sales.

Understanding the Slowdown Perimeter

It is now clear that only VLAN_Sales was impacted by this slowdown, caused by a longer network RTT. The next step would be to determine whether this issue impacted all clients in the zone or if it was just limited to specific clients.

To achieve this, the Performance conversations for the application Samba_CIFS, for the zone VLAN_Sales, can be displayed.

The following conclusion can be made:

• Only the clients 192.168.20.205 and 192.168.20.212 seem to be impacted; other clients have very short RTT values.

To verify this, it is necessary to confirm that these two hosts are the only ones affected and determine whether they were impacted solely when accessing the Fileserver. This can be done by examining the Performance conversations between VLAN_Sales and the Private zone. The following conclusions can then be drawn:

• Not only 192.168.20.212 and 192.168.20.205, but also 192.168.20.220 and 192.168.20.50 were impacted.
• The Samba_CIFS (access to the fileserver) was not the only impacted application; SMTP, HTTP and the Web Intranet SecurActive were also impacted.

Actions to take following the analysis:

• Review the windowing configuration on the operating system of the affected hosts (a high value is normal behavior).
• Examine the host's resource usage, including CPU and RAM utilization.

Alternative Scenarios

• In the case of retransmissions, verify if they are occurring on the same edge switch, and then inspect the interface configuration and any media errors.