SQL Stress Tool基准测试

　　我们的第一个基准测试是在.NET中自己编写的，用ADO.NET来连接数据库。 在基准测试的时候大小超过14GB的AnandTech论坛数据库被用来做源数据库。为了讨论的方便，我们将把这个基准测试工具称为SQL Stress Tool。自我们第一次用它以来，我们已经做了一些升级；现在它支持Oracle和MySQL。我们还为了这个测试和将来的测试，把测试时间调整为20分钟。这样做的理由是为了确保我们对将来的64 bit测试使用尽可能多的内存。

点击放大

　　SQL Stress Tool让我们能够指定下列选项：用于测试的一个基于XML的工作量文件，测试应该运行多久，以及其中应该使用多少个线程来载入数据库。XML工作量文件包含了我们想要对数据库执行的查询和一些随机ID发生器查询，后者以被用到的ID结合我们的工作量查询开辟一个内存常驻数组。使用随机ID的目的是为了通过选择随机数据而让测试尽可能地接近实用。

　　工作量实例：

　　Select1
　　select count(iuserid) as usercount from ftdb_forumusers where iforumid = 1

　　Select2
　　select count(u.iuserid) as currusercount from ftdb_users u,ftdb_forumusers fu where fu.iforumid = 1 and u.iuserid = fu.iuserid and dtlastvisiteddate > '[q]qGetLastVisitDate[/q]'

　　随机ID发生器实例：

　　qGetLastVisitDate
　　select dtlastvisiteddate,newid() as ldate from ftdb_users where dtlastvisiteddate is not null order by ldate

　　对测试使用的工作量是基于论坛每天的使用的。我们接受最常用的查询，并把它们加入工作量中。像阅读帖子和讯息，获取用户信息，发帖子和讯息，以及阅读私人讯息这些功能是最常见的了。测试的一个周期是20分钟，冷启动以后开始运行。在每个连续运行的测试中间重新启动SQL。

　　这个测试的重要性在于它是无限接近于实用的；对于我们来说，在这个测试中的性能直接影响到我们为我们自己的IT构架做出怎样的升级决定。

SQL Stress Tool结果

　　SQL Stress Tool结果与我们以前使用这个工具获得的一些结果有点不同。我们对工具本身做了一个修补，它对大量的查询更敏感了。而且，我们把测试时间延长到20分钟，并根据我们当前的FuseTalk版本改变了一些查询。

　　在这个测试中四Xeon大获全胜，这应该归于被CPU操作的数据不大。Xeon不必像它在后面的重工作量测试中做的那样频繁地为了数据让处理器全速运行。四个拥有1MB L2的Xeon 3.6把双875拉下了5％的差距，而拥有8MB L3的3.3GHz获得了接近10％的领先。很明显，由于数据集较小，我们没有完全利用到Potomac Xeon提供的8MB L3。