数据库复制性能和推送模式性能测试

　　数据库复制就是由两台服务器，主服务器和备份服务器，主服务器修改后，备份服务器自动修改。

　　AD：

　　使用了数据库复制的人，首先担心的就是主服务器和备份服务器的性能消耗问题，本人也是对此十分担忧，查了半天，基本上没发现类似的测试说明，就自己测试了一下，下面为测试的结果，仅供参考

　　我采用的是数据库推送的复制模式，下面测试页是基于此模式

　　因为数据库复制主要是I/O操作，所以在此测试主要测试服务器的硬盘读写操作，此次测试主要监控的对象为

　　avg. disk queue length(下文简称为dql) 简单可以理解成磁盘数据吞吐量的外在体现。通俗的将就是曲线上随便取两个不同的点，高的一点说明正在的进行读写操作的量比较大，反之，比较小。

　　第一种情况：1秒钟写入一次数据，一次数据写入三个表，循环写入10000条

　　过程：关闭复制，单纯的写入，dql平均值最大值为：0.126

　　开启复制，同步性的写入 ， dql平均值最大值为 ：0.132

　　结论：鉴于这种比例，1秒钟一次是这种小数据库的写入，同步问题，我们可以完全忽略了

　　第二种情况：忽略等待时间，一次数据写入三个表，死循环写入10000 次数据

　　过程 ：关闭复制，单纯的写入，第一次测试：dql平均值最大值为：3.05-3.08 第二次测试：2.2-2.30

　　开启复制，同步性的写入 ， dql平均值最大值为 ：3.06-3.10 第二次测试：2.2-2.34

　　结论：可以由于两次测试间隔时间比较长，机器的情况不一致，但是结果很明显，都是相差不大

　　第三钟情况：关闭复制，主服务器写入 10000 次数据 ，每次写三个表，然后开启服务器，主服务器的 dql基本没变化，因为是复制服务器写数据，和主服务器关联性不大

　　就上述情况来看，复制基本上不会影响主服务器的性能消耗，但是，我们通过监控SQL Server Profiler 会发现，出现大量的复制监视器，这种复制监视器，会非常消耗服务器的性能，造成服务器缓慢，因为是推送模式，所以主服务器要时刻监控自己的变化情况，而造成性能消耗，如下图

　　如何解决这个问题呢?我们首先会想到，减少主服务器的监视频率即可，打开复制监视器，

　　右键--》发布服务器属性设置，修改一下刷新速度，一般我们可以接受的是范围是30-60秒的延迟

　　修改后，我们在去SQL Server Profiler 查看，就会发现基本上消耗就会很少了

　　如果你的服务器复制模式为订阅模式，那么你去--代理配置文件---》分发代理--里面去修改你的订阅时间即可。

原文转自：http://www.ltesting.net