5.29. Can this application be optimized?

This question comes often to the Riverbed TAC and the answer is mostly "Most likely".

5.29.1. On individual TCP sessions

The Steelhead appliance optimizes in three ways: TCP optimization, Data Reduction and Latency Optimization.

The first one, TCP optimization, changes the characteristics of the TCP session, for example the TCP Window which allows more data outstanding over the WAN. If the client doesn't support these features in its TCP stack, the TCP optimization of the Steelhead appliance will improve the throughput.

The third one, latency optimization, only works if the application uses certain protocols like CIFS, NFS and HTTP. If the application is using these protocols to access remote data, then latency optimization on the Steelhead appliance will improve the throughput.

The second one, data reduction, works most likely unless the data stream is compressed or encrypted. If the data is compressed, then the configuration of the application should be checked to see if the compression can be disabled. If the data is encrypted via SSL, then the traffic can be optimized if the server SSL certificate and the server SSL private key are available. If these two items are not available, then the traffic cannot be optimized. If the data is not encrypted via SSL, then the traffic cannot be optimized.

If that application is already being optimized, the ratio of the traffic on the LAN and WAN side can be checked:

Figure 5.208. An encrypted or compressed TCP session

CSH # show connections opt filter 10.16.5.39 full
T  Source                Destination           App    Rdn Since
--------------------------------------------------------------------------------
O  10.0.1.1         2067 192.168.1.1      1039 TCP     0% 2013/03/20 11:45:47
                   Peer: 192.168.1.6      7800 Inner: 37024
            Outer Local: 10.0.1.6         7801   WAN: 2299KB
           Outer Remote: 10.0.1.1         2067   LAN: 2003KB
    WAN Visibility Mode: Correct Addressing
                  Flags: cfe,sdr,lz,te=0,pe=0

In this case the protocol is TCP (so no skewing because of a read-ahead feature in latency optimization) and the amount of bytes on the WAN side is larger than the amount of bytes on the LAN side, making the Reduction 0%. We found out that the application used compression on the wire. After the application configuration was changed the amount of bytes on the LAN side increased but due to the data reduction of the Steelhead appliance the amount of bytes on the WAN side decreased.

Figure 5.209. An formerly compressed TCP session

CSH # show connections opt filter 10.16.5.39 full
T  Source                Destination           App    Rdn Since
--------------------------------------------------------------------------------
O  10.0.1.1         2103 192.168.1.1      1039 TCP     9% 2013/03/20 11:57:12
                   Peer: 192.168.1.6      7800 Inner: 37041
            Outer Local: 10.0.1.6         7801   WAN: 599KB
           Outer Remote: 10.0.1.1         2103   LAN: 6412KB
    WAN Visibility Mode: Correct Addressing
                  Flags: cfe,sdr,lz,te=0,pe=0

5.29.2. Overview per protocol

In the Traffic Summary under Reports -> Networking -> Traffic Summary, it will be possible to determine the overal performance of a certain protocol:

Figure 5.210. The traffic summary report

The traffic summary report

Here can be seen that traffic on TCP port 3268, 49156 and 5989 is not being reduced in size at all. The total percentage of traffic for these three ports is 9.53%, which is quite big. If the application settings cannot be modified to allow a better data reduction, disabling optimization for these ports via an in-path rule would prevent the data store to be filled with useless references and free up TCP connections.