“订单登记”强度测试：衡量企业级性能 在进行测试中，也听到一些抱怨的声音，他们认为我们数据库的压力强度不足以成为影响企业级别用户作出选择的程度，显然企业级应用是更严峻的考核环境。
幸运的是，我们临近一个大公司，他们可提供真实的企业级SQL 压力应用。由于签署了保密声明，很遗憾不能透露该公司的名称。在测试中，我们并不对数据库进行任何修改，而只是进行整体的交互使用，但有需要的话我们可阅读应用程序的配置文件，以更好地理解测试结果。
我们使用了一个Order Entry system(订单登记系统)作为数据库的模拟交互测试，数据库的所有交互都是通过储存进程来进行。储存进程使用的测试如下：
sp_AddOrder - inserts an Order
sp_AddLineItem - inserts a Line Item for an Order
sp_UpdateOrderShippingStatus - updates an status to "Shipped"
sp_AssignOrderToLoadingDock - inserts a record to indicate from which Loading Dock the Order should be shipped
sp_AddLoadingDock - inserts a new record to define an available Loading Dock
sp_GetOrderAndLineItems - selects all information related to an Order and its Line Items
以上代码仅是表明了储存进程的整体函数；显然在储存进程中还要执行其它操作，比如确认和检查。在Line Items 中，每个订单都会有一个在１到３之间的随机数，随即数是Line Items 从一个大约1500 Line items 为订单作出的选择。
每次测试运行１０分钟，并重复３次，测试结果取３次的平均值。读取和写操作维持在10:1 的比例 ，其实在该数值上我们测试人员间曾进行过长时间讨论，怎样的比值才最符合真实环境呢？
应用程序使用C#语言开发，所有数据库连接都是用ADO.NET 和20线程：其中１０个读取和１０个插入。
为了确定IO 不再是系统的瓶颈，每个测试的数据库都从空的开始，然后膨胀到足够大在测试中不能快速执行为止。此外，在客户端和服务器端使用了千兆交换机。在执行测试过程中，在服务器或者监视软件没有任何程序运行。任务管理器、Profiler和性能监视器都建立在测试的基线，在测试过程中并不执行。
在每个平台测试的开始，服务器和客户工作站都进行重新启动，确保系统干净和一致的环境。数据库被复制到8-disk RAID 0 阵列，并且没有其它任何数据，最大限度减少碎片。在三次测试中的每次，数据库都将被删除，重新复制到干净的环境。SQL Server 不进行重新启动。
订单登记”强度测试结果
从测试结果可知，Opteron 和Nocona 架构的区别对性能影响很大。Opteron 250 与Opteron 248 相比，在时钟频率提升8% 情况下，性能增加了7% 。Nocona 在小中型工作负荷测试中表现理想，但在大型应用似乎就差强人意了，由于Xeon 处理器分享前端总线的特性，严重影响了其性能发挥。我们对比3.6GHz Nocona 和3.2GHz Prestonia 的性能可知，它们的性能增幅仅仅为1% ，这完全在偏差范围之内。Prescott 核心的长管线，和有限的总线，限制了Nocona 的性能。当然Nocona 的L2 Cache 仅有1MB ，少于Prestonia Xeon ，性能增益如此，也是情有可原。
总结 在小到中型强度测试中，Intel 给我们的印象深刻，性能媲美Opteron 250 处理器。这要归功于400MHz 的时钟频率和266MHz FSB 提升。在企业级的应用则比较有趣，Xeon 分享FSB 的架构拖累了其性能发挥，Prescott 核心的长管线也是一利差因素，这使得Nocona 3.6GHz 与Prestonia 3.2GHz 相比仅有1% 的性能提升。
AMD 表现出新架构的强劲潜力，点到点HyperTransport 和内置的内存控制器让Opteron 在服务器平台发挥理想。不过AMD 的性能并没有转化为市场份额，这是比较郁闷的事情。
2006 经营许可证编号： 粤B2-20050807
