I've been looking at the log_send_rate values as part of troubleshooting a latency issue we have in one of our production environments.
I have proposed to Microsoft that their definition of the field is wrong, as mentioned here (http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx).
"Rate at which log records are being sent to the secondary databases, in kilobytes (KB)/second."
I think my definition below is better. It is...
“The rate at which log records are cleared from the send queue”, and log records can only be cleared from this queue when they have already been hardened on all secondary’s, and that can only happen when they have already been sent and recieved, irrespective of how long it took those records to arrive, and how long it took them to be hardened, and how long it took for the secondary to send the acks back to the primary.
That’s a very different definition, even if they look cosmetically the same. Data can be removed from a local in memory queue (log_send_queue) much faster than it can be sent to the secondary's in another region, country or datacentre.
@Thomas (I'm still too noob to add comments here, apologies. If easier I can provide my work email and we can discuss offline, and update here when consensus is reached?)
Unfortunately, while your point is correct, its not the point at stake. Yes, it is harder to correlate for all the reasons you've described, but its not the issue I'm trying to highlight.
The point is, that the field "log_send_rate" in the DMV is not actually the rate at which log records are sent to the replicas.
More accurately, its the rate at which log records are being removed from the send queue, AFTER they have ALREADY been sent to secondary, hardened at the secondary, and then sent an ack back to the primary. Only then can they be cleared from the primary send queue.
That's a completely different meaning from that listed in link I included in my first post. Its also much easier to see the discrepancy when you are dealing with cross regional (such as London to New York) send rates, rather than send rates from and to the local datacentre.