SANHQ will split off the metric of replication latency as a seperate figure.  Look in the Target group, under I/O > Experimental analysis, and on the left hand side, you will see Average latency for reads, for writes, and for "inbound replication"

Thank you both. What is interesting is ever since I implemented a replication partner, my average latency on the main page has gone through the roof. That's why i was askign.

Hi Don, no its not local replication and yes the latency is only high while replicating. I am debating on increasing the TCP windows size to 2MB where the replicated array is for replications only.

Thank you for the advise.

By high latency, what sort of numbers is it spitting back at you?  And what does the topology look like between your source and your target?

I have seen spikes of 200ms from the main page of SanHQ. My volumes are staying between 1 and 7ms though. When I ssh into an array and ping array to array over our WAN link, it's a 30-40ms latency on a 1Gb link. So with that latency, you can image my speeds aren't ideal but my concerns were around latency with regards to impact.

sketchy, i will be in your boat for speed within the next few months. For the time being I am trying to get this to work though.I am running one replica at a time. One question I have is if up-ing the TCP windows size to 2MB will make a difference? Also, how many TCP threads or streams is this using for the replication? Is there anyway to increase this?

I'd experiment with doing a single replica at a time.  As Don mentioned, running multiple replicas at the same time can skew the numbers because it is for the most part splitting them up evenly.  And replicas do use a larger block size (256KB, right Don?).  I run a fiber based Metro E circuit that always reports less than 1ms latency on pings, but I have replicas that, according to SANHQ will have an averaged 800ms latency.  If I calculate out the overall efficiency of the transfer, it works out to something like 95% of the theoritical maximum, which is pretty good.  So perhaps some of the figures that SANHQ is calculating might be misleading.  Certainly worth investigating.

And I might add that the original poster will want to do some hand calculations on replica times for a single replica job.  Depending on how far away it is from 100% protocol efficiency (that won't ever happen of course) that will give you and idea if your effective throughput is not what it should be, and worth investigating further.

anyway to adjust that? Have two iSCSI connections per task?

And that was what I was hoping for. Thank you for the help.

Chalk me up as one of the guys who can't get enough bandwidth.  ...Or can't get too small of a replica.  (hint hint)

:-)

I think I will give the TCP windows size change a go ahead where I have a 1Gb WAN link but high latency....until I get my new pipe.

Any idea about how many TCP streams are used during a replication? Is it just one or can I have many TCP connections for a replication?

Thank you

yup, I hear ya. Smaller datastores is actually what I am tossing back and forth. Although, vCloud director does not like datastores to be removed.

Yep.  I've found the smaller datastores to be easier to work with when it comes to sizing out my replication policies.  When you consider that replication is volume based, the more difficult it becomes if their are constrainst on the target side for size, or any bandwidth issues.

So to have more TCP sessions, I need to have more replications. In terms of more TCP sessions, do I need more outbound replica collections or can it be in the same collection just different replica within that collection?