- Justin Baker
- November 6, 2009
WANOp is increasing popular these days and sometimes gets talked about like it's a panacea to solving performance problems. The reality is WANOp is not well suited to ease all performance pains. In some instances, WANOp can actually break things. Think about it: WANOp devices like those from Riverbed are designed to accelerate certain protocols, intercept connections, inject certain elements to make the transaction go faster, sometimes they even serve as full proxies and terminates connections. This is a complex process that may have unexpected side effects.
We had a customer that just deployed WANOp solutions. Almost immediately, they saw some weird interactions with FastTCP. The connections were stalling intermittently and even being reset for no apparently. The additional layer introduced by the WANOp device fundamentally changed certain behaviors on the network.
That's where ExtraHop comes in. ExtraHop provides full visibility for the WANOp system and the application environment. We came in, set up shop, and was able to isolate it, and changed certain settings to eliminate the problem. After the fact diagnosis isn't all we can do for WANOp projects either. Prior to deployment, we can look at the centralized CIFS servers, and identify whether a certain environment makes a good candidate for WANOp. For example, with our CIFS protocol support, the ExtraHop system can identify excessive file locking, in which case, WANOp won't help improve the performance at all. In addition to that, we can also help in benchmarking the before and after performance. This way, you have concrete proof points for how much the WANOp deployment is helping with performance improvements.
This is a companion discussion topic for the original entry at http://www.extrahop.com/post/blog/stories/wan-optimization-considerations/