Guidelines for Slow Application

Hypothesis

One or several end users complain about a slow access to a specific application – a fileserver.

Prerequesites

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 listening interfaces of the probe. Where to start: a global view of the application performance!

Display the Application Dashboard for a relevant period of time. We can easily observe a peak in SRT from 6 to 18:15. From the breakdown by zone, we can easily conclude that only one zone has been impacted.

By clicking on that zone, we can see this client zone’s application dashboard:

From this, you can conclude that only one client (= user) was impacted. This issue was definitely due to a slow response of the server; it may be due to an application issue or a request which is specifically hard to respond to.

Inspect the Application Dashboard for a relevant period in the past (48 hours for example).

This dashboard shows in the upper part the evolution of the End User Response Time (EURT) through time for this fileserver.

• We can easily observe that the quality of experience of users accessing this application got much worse yesterday afternoon.
• We can easily identify that this was due to a degradation of RTT (Round Trip Time - indicator of network latency) and not to the Server Response Time (SRT) or the Data Transfer Time (DTT).

From this graph, we can conclude that the server and the application are likely not related to the slowdown. By looking at the two bar charts which show the breakdown by server and by client zone, respectively, we can draw the following conclusions:

• This application is distributed by one server only (192.168.20.9).
• The EURT vary in large proportion between client zones, mainly because of RTT.
• VLAN_Sales has a much worse access to the application than VLAN_R&D, mainly because of the network latency.

To confirm our first conclusions, click on the peak of EURT in the upper graph. We can narrow our observation period to understand better what happened at that point of time.

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

Understanding the perimeter of the slowdown

We now know that only VLAN_Sales was impacted by this slowdown, due to a longer network RTT. We, therefore, need to understand whether this was general (i.e., impacted all clients in the zone) or isolated to certain clients.

To achieve this, we can simply display the Performance conversations for the application Samba_CIFS for the zone VLAN_Sales.

We can draw the following conclusion:

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

To confirm this, we need to check that these two hosts are the only ones impacted and check whether they were impacted only when accessing the Fileserver. To do so, we look at the Performance conversations between the VLAN_Sales and the Private zone. From this, we can draw the following conclusions:

• 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 be taken after that analysis:

• Check the windowing configuration on the operating system of these hosts (if high value, this is normal).
• Check the level of usage of the host (CPU, RAM usage).

Alternative scenarios

• If we had seen some retransmissions, check whether they are all on the same edge switch and check the interface configuration and media errors.