well, there’s only one way to find out…FIGHT!
Ok apologies for invoking a TV show known only in the UK (Harry Hill’s TV Burp), but it seemed a good way to frame the question.
WAN Optimization products deliver you mainly two things:
1) reduction in data across the network, allowing more users/applications to share a connection. This is “offload”.
2) acceleration of data transfer giving faster response times when browsing, copying files, backing-up, accessing applications.
The “offload” part is more or less fixed because it’s delivered by de-duplication and compression algorithms. Provided the WAN Optimizing appliance (hardware or virtual) can keep up with the data-rates it will squish the data volumes by the same amount.
The acceleration part is less predictable in the abstract. Processing the data takes time. When deployed correctly the processing time is far less than the time gained in sending less data, pre-fetching, data caching data etc. But no-one would recommend deploying WAN Optimization on a LAN. As the latency of a WAN connection goes down, and the bandwidth goes up, you approach a realm where there is no appreciable acceleration, and all you get is offload.
Now offload can be very desirable. Even on its own; for example if your site connection comes to a standstill every time someone emails a large attachment across the company. Or any time someone does a large upload/download. Or when back-ups are running, then offload alone will remove the bottleneck and make people happy.
High Latency Connection
The other extreme is a fat high-latency connection. You’re not going to care about the offload if the bandwidth is already paid for. (although you could consider buying less). So what will interest you is the acceleration. The acceleration you’ll get is a function of the chattiness of the native protocol(s), the repetitiveness of the data transferred (collaboration around content, software updates, back-ups etc) and the size of cache you can afford to deploy.
If you have a fat low-latency pipe, that’s never very full (just like the LAN), you’re just not going to notice WAN Optimization in action. If you don’t have a headache, taking a pill won’t make you feel any better. (I’m talking painkillers here of course, let’s not wander off).
So… when planning a Proof of Concept for WAN Optimization, make sure you know what problem(s) you’re trying to solve and what success would look like. And then you can move on to “I like Replify Accelerator, and I like <Product X>, but which is better?” Well Replify Accelerator of course.