This question comes often to the Riverbed TAC and the answer is mostly "Most likely".
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
In the Traffic Summary under Reports -> Networking -> Traffic Summary, it will be possible to determine the overal performance of a certain protocol:
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.