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.
