cparker4486 wrote:The WAN accelerator is running off an Equallogic which has the capability of much greater than 9MB/s read/write.
It's not about MB/s, it's about I/O latency. The WAN accelerator doesn't read/write a lot of data from a MB/s perspective, but it does read/write many small chunks of data so the faster those requests can be serviced the better. If you want to get the best throughput from the WAN accelerator you need fast SSD for the global cache with a low latency profile to be able to service small block read/writes very quickly. If you have both your repository and global cache on the same disks, this is only going to make things even worse, and if you have both the source and target systems backed by the same disks, things are just getting slower.
But yes, R2 may offer some improvements because of some additional optimizations, however, you'll only get so far if you're using spinning media for the global cache due to I/O latency. If you don't have an option for SSD, then using a global cache that's roughly half the size of RAM seems to offer a small boost. Also, the majority of savings come during incremental runs, not full runs. It will be interesting to see your results from R2.
The design of WAN accelerator is to reduce the amount of data that had to be transferred over slow WAN links, effectively increasing throughput. For customers with links that are less than 40Mbps even spinning media can offer significant increases in performance, but it won't necessarily saturate that link. For example your seeing ~72Mbps, so if your real link is slower than that, it's still a benefit. Even if your link is faster than that, if it's shared with other traffic the reduced bandwidth may be desired. If you want to get maximum performance from links more than about 10Mbps, you'll likely need SSD for global cache, but you still won't likely see performance greater than around 40-50MB/s for total throughput, which is still ~4x faster than a 100Mbps link.
