我工作的公司正在为我们的一个客户build立一个分公司。 我们在每个位置都有1.5 Mbps的向上/向下T1，每个位置的Cisco RV042路由器在两个位置之间托pipe一个Gateway to Gateway VPN隧道，我们在主办公室有一台SBS 2008服务器，分公司。 我们设立了DFSR来在两个办事处之间来回复制特定的股票。 我们不使用名称空间，只是DFSR。
我们的问题是，在分支服务器上打开DFSR服务时，networking延迟增加100倍，达到200倍。 我测量的延迟只是使用连续的ping从我的笔记本电脑运行到外部网站。 在DFSRclosures的情况下，平均延迟为〜11.5 ms。 在DFSR打开时，它在〜1100和〜2500毫秒之间变化。 DFSR时间表从星期一到星期五从上午6点到下午6点不可复制，在其他时间完全复制。 即使在计划表示不应发生复制的时候，延迟也会增加。
作为testing，我将复制计划从UTC切换到本地时间。 我曾经假定UTC会查询和使用本地时间源的UTC偏移量。 （现在想想，我不知道为什么我这样做）。我没有看到立即改善，但是在写这个问题之前，我去了几个DFSR相关的文章，现在几分钟后，我看到了延迟已经下降了。 Ping现在报告的时间在300到400毫秒之间，我从Speakeasy.net Speedtest获得了“好的”结果。
所以我想这成了两个部分的问题。 这是DFSR期望增加的延迟吗？ 如果没有，我可以做些什么来进一步调整，调整或debugging？
谢谢阅读。 如果有什么不清楚的地方，或者您想了解更多信息，请告诉我。
由于没有复制，因此在下class时间内不应看到任何延迟增加。 机会是，你只是configuration错了（你似乎已经find了你的UTC评论）。 当您进行更改时，更改不会立即应用。 他们必须复制到所有可能需要几小时的成员，具体取决于您的AD拓扑。
所以我想这成了两个部分的问题。 这是DFSR期望增加的延迟吗？
在允许复制的时候，绝对是。 1.5Mbps不算什么，如果有大量数据需要复制，服务器可以很容易地将其饱和。
如果没有，我可以做些什么来进一步调整，调整或debugging？
仔细检查你的configuration，并使用像dfsdiag这样的工具来查看是否有积压或其他问题。
注意：使用ping测量延迟实际上不是一种故障排除技术。 您应该在每个站点的路由器/交换机上监视它。 现在1.5Mbps不是很多。 你的performance可能整天都很差，这取决于你的办公室里有多less人。 您应该在路由器的正常日子里进行基线测量， 然后进行比较。