性能测试

　　这里关注的是测试SQL Server 2008透明数据加密的性能。它和一个没有加密的数据库比较起来性能是怎样的?SELECT/INSERT/UPDATE 的混合对性能结果有什么影响?我们将看看这些结果与Microsoft发布的预期相比是怎样的，还包括全部的代码，以便你可以在你的环境中再次运行这些测试。

　　测试系统细节

　　对于这个测试，我使用了这个系统：

　　4 64位双核AMD处理器

　　16 GB RAM

　　直接附加的SCSI驱动

　　Windows Server 2003 R2 Enterprise x64 Edition

　　SQL Server 2008 (RTM)

　　测试架构

　　图1

　　每个表有一个聚集主键在ID字段上。

　　非聚集索引：

　　· Vendor：非唯一索引BusinessName

　　· Card： 唯一索引CardNumber、

　　· Card：非唯一索引SecurityCode、

　　· Card：非唯一索引SecureString

　　· Purchase：非唯一索引CardID

　　· Purchase：非唯一索引VendorID

　　测试细节

　　测试脚本是模仿一个OLTP 工作负载。它涉及三个表：Vendor、Card和Purchase 。

　　“执行概要”

　　这些测试使用多个对一个SQL脚本的同步调用，这个SQL脚本循环调用存储过程，首先加载然后读取、插入或更新数据。

　　详情

　　这个测试的“驱动”是一个简单框架叫做Hummer 。它使用一个.bat 文件来运行一些初始的建立脚本，然后启动n个同步进程，每个都运行相同的脚本。思想是模仿多个客户端竞争数据库资源。每个脚本包含一个对DELAY的临时调用。这帮助使得多个处理器可以共享数据库资源。它还更好地模仿了一个真实的OLTP 工作负载。

　　有多个测试，它们的参数不同。你可以在下面的图表中看到所有的细节。让我们看看Test Run 7作为一个例子。

　　.bat脚本执行三个步骤：

　　· 删除和重新创建这个数据库。

　　· 创建表和索引。

　　· 创建存储过程。

　　· 启动10个进程，每个都运行主测试脚本。

　　CREATE DATABASE 脚本创建Data文件，初始大小为100MB，日志的初始大小为20MB，每个都设置为增长10%。

　　主测试脚本执行这些步骤：

　　· 执行DBCC FREESYSTEMCACHE 。

　　· 执行DBCC DROPCLEANBUFFERS 。

　　· 启动时延迟5秒(使得所有的进程都启动)。

　　· 循环100,000次

　　o 读取控制参数(SP调用)。如果测试结束，就停止。(这也使得你可以在它运行时改变参数或停止测试。)

　　o 每1000次循环，延迟1秒。

　　o 第一次10,000循环，创建一条Vendor记录(SP调用)。

　　o 第一次10,000循环，创建一条Card记录(SP调用)。

　　o 第一次10,000循环，创建一条Purchase记录(SP调用)。

　　o 每10次循环：

　　§ 10次中的第4次：读取一条Card记录。

　　§ 10次中的第3次： 更新一条Vendor记录。

　　§ 10次中的第3次：插入一条Purchase记录。

　　(在第一次10,000循环之后，所有的读取和更新动作都是在这个集合中的某个随机记录上。)

　　· 结束循环

　　这个过程是运行于Base(未加密的)和TDE数据库上的。

　　有一点很重要，就是了解我们在每个进程中插入10,000条Vendor、Card和Purchase 记录。所以，插入的记录总数(在最初集合中)是每个表100,000条记录。

　　消耗的时间只是循环操作的时间，不包括数据库创建或任何其它的建立操作。

　　结果

　　所有的测试中参数是一致的：

　　· LoopMax(最大循环数)：100,000

　　· Process Count(进程数)： 10

　　· Records Created(创建的记录数)： 每个表每10,000个进程

　　· “AvgET”时间是毫秒单位。

　　图2

　　所有的16个测试平均为6.36%。在这些测试中有一些变化，但是我相信这很好地指示了为一个事务型工作负载使用TDE 的成本。

　　记住，这是在完全相同的硬件上运行完全相同的工作负载。

　　CRUD形式?

　　我没有看到一个强烈形式显示比如读取要比写成本要低。当然有显示读取比写成本要低，但是这不是很一致的形式。

　　CPU

　　TDE 怎么影响CPU使用?这是一个很难回答的问题。看起来适合的方式是根据多次运行显示代表性的CPU图表。你可以根据这些图表得出你自己的结论。我的看法?没什么不同的。TDE不会显著地增加CPU成本。

　　注意，为了一致，我在每个测试中相同的点捕捉这些图片(就在第70,000次循环完成的时候)。

　　图3 完全读取测试(10/0/0)——Base

　　图4 完全读取测试(10/0/0)——TDE

　　图5 完全写测试(0/5/5)——Base

　　图6 完全写测试(0/5/5)——TDE

　　总结

　　平均消耗时间成本是6.36%。这证实了“在一些测试中。。。，测量到的成本是低于5%。”得到了“静态”加密的数据，那么这看起来似乎是合理的成本。

　　对SQL Server 中的新特性运行了一些类似的测试，惊奇地发现TDE对运行一个工作负载的时间的影响如此之小，而且它对CPU利用没有显著的影响。在我看来，这是非常成功的。TDE对你的处理增加了很小的成本，它不需要你再支付什么(假设你已经购买了Enterprise版本)，而且你根本不需要改变你的应用程序。开发团队提供了这样一个强大的新特性真是太棒了。