Order Entry重点测试 - 测量企业级性能

　　关于我们的论坛数据库测试，我们常收到的一个抱怨就是它不够困难，不足以让一些企业用户根据结果做出明确的决定。

　　为了尽可能地满足每个人的要求，我们与一家公司进行了非常密切的合作，它能够为我们提供真正的企业级SQL重点应用程序。不经同意，我们不能透露向我们提供应用程序的公司的名字。所以我们不会探究应用程序的细节，只是提供一个数据库交互的概括，以便用户能够了解这个应用程序的大概，更好地理解测试的结果（以及它们与用户的数据库环境有何关联）。

　　我们将使用Order Entry系统作为这个测试如何与数据库结合的一个类比。所有与数据库的交互是通过存储程序。测试期间用到的主要存储程序有：

　　sp_AddOrder - 插入一个订单
　　sp_AddLineItem - 为一个订单插入一个项目
　　sp_UpdateOrderShippingStatus - 更新出货状态
　　sp_AssignOrderToLoadingDock - 插入一个记录来指出订单应该从哪个码头出货
　　sp_AddLoadingDock - 插入一个新记录来定义一个可用的码头
　　sp_GetOrderAndLineItems - 选择关于一个订单和它的项目的所有信息

　　上面只是对存储程序功能的一个概括；显然存储程序还执行确认和审计等操作。

　　每个订单有多少个项目是随机的，范围从一到三。为一个订单选择项目也是随机化的，从大约1500个项目的集合中选择。

　　每个测试运行10分钟，并被重复三次。采用三次测试的平均值。读取对写入的比例保持在每10次读取一次写入。我们就读取对写入的比例应该是多少才能最好地服务于基准测试争论了很久，然后我们发现那没有确定的答案，所以我们采用了10。

　　应用程序是用C#开发的，而所有的数据库关联是用ADO.NET和20个线程实现的 - 10个用于读取，10个用于插入。

　　所以为了确保IO不会成为瓶颈，每次测试以一个空数据库开始扩展，以确保测试期间不出现自动产生的记录。此外，在客户端和服务器之间使用了一个Gigabit开关。在测试的执行期间，服务器或监控软件上没有应用程序运行。在设立用于测试的基线时使用了任务管理器，配置文件和性能监控器，但在测试执行期间一概不用。

　　在每个平台开始的时候，重启服务器和客户端工作站以确保干净而稳定的环境。数据库总是被复制到没有其它文件存在的8磁盘RAID 0阵列，以确保运行之间的文件放置和碎片是一致的。在三次测试中的每一次结束之后，删除数据库，再次复制一个空数据库到空白的阵列上。SQL Server不重启。

Order Entry结果

　　正如下面的结果中可以看到的，能够得出一些有趣的结论：

• 双Opteron 875较最快的四Xeon领先了18％。这应该是正常的，因为在过去我们已经见识到，Intel FSB构架的内存带宽限制使得四个Xeon不能充分地发挥作用。另一方面，Opteron的集成内存控制器让它们获得了领先。
• 四Xeon 3.3GHz超大的L3缓存使得它超过了四Xeon 3.6GHz达16％。
• 拥有667MHz FSB的四Xeon 3.6GHz只能够胜过双Xeon 3.6GHz 800MHz FSB大约5％。
• 双Xeon能够超过双252的速度达2％，而领先单875有5％。在这里Xeon的成功可能归功于额外的L2缓存。
• 双Opteron 875展示了惊人的威力，在相同时间内比单个Opteron 875多处理了52％的操作。

　　为了对这个基准测试的尺度有一个概念，我们给出了每秒调用的存储程序的图表。我们决定集中在存储程序数量/秒，而不是事务数量/秒，因为事务的定义可能与业务上下文或技术方面的上下文有关。