摘要：
Profiler的功能之一是监视和报告SQL Server数据库在各个层次上的性能，但许多人忽视了Profiler作为一个Web开发工具的作用。其实，它可以用来观察Web应用程序如何与服务器交互，帮助我们分析代码的效率。
正文：
在SQL Server 2000和7.0中，许多人忽视了Profiler作为一个Web开发工具的作用。Profiler的功能之一是监视和报告SQL Server数据库在各个层次上的性能，可以用来观察Web应用程序如何与服务器交互。此外，Profiler还可以帮助我们分析代码的效率。例如，用Query Analyzer对代码进行优化之后，我们可以用Profiler测定Web应用的性能是否提高。
为了生成用来分析Web应用与SQL Server通信情况的性能数据，首先要测试几个页面。选择一个能够为应用模拟出实际负载情况的测试工具，然后运行Profiler观察负载情况。例如，你可以下载Web Application Stress Tool，地址在http://webtool.rte.microsoft.com。Application Center也包含了该工具的一个升级版本，Application Center是Microsoft的一个新产品，当前正在进行Beta 2测试。
用Profiler运行跟踪的时候，保存结果的文件名字应该容易识别。先进行几次测试，接下来就可以比较每一步骤的结果。每次运行之后，你都必须启动一个新的跟踪，而且每次都要保存跟踪。另外，你还可以保存跟踪再重演负载情况，模拟数据库上的实际负载。必须注意的是，用Profiler或Query Analyzer重演负载只模拟出一个负载，它与通过Web应用程序加载负载是不同的。为了说明Profiler的应用，下面是我进行的四个简单测试。
▲ 测试一：在ASP脚本中运行一个简单的查询。首先，我编写了Listing 1显示的简单ASP脚本Database.asp，这个脚本包含了RunWithRS函数。然后，我编写了Web Listing 1的脚本FirstData.asp，它调用RunWithRS函数执行下面的查询：
sSQL = "select ckey1,col2 from testtable
where ckey1 = ’a’"
我在两个Web服务器上运行了FirstData.asp脚本。第一台服务器是Windows 2000工作站，600 MHz Pentium CPU，192MB的RAM。第二台服务器是Toshiba Tecra（133MHz Pentium，144 MB的RAM），运行Win 2K，同时运行SQL Server 7.0。
我启动Profiler，设置跟踪的属性，然后开始了一个跟踪。跟踪结果请参见图一。在第一次测试中，运行时间是相同的。这个结果就象我们预料的一样，因为无论从哪一个系统访问数据库都应该报告同样的响应时间。测试中唯一的区别在于Web服务器，但它不会影响数据库服务器的运行。
▲ 测试二：运行存储过程，脚本文件是FirstData2.asp。在第二次测试中，我用下面的SQL命令创建了存储过程：
CREATE PROCEDURE GetTestDataByKey
@ckey char(1)
AS
SELECT ckey1,col2 FROM testtable WHERE ckey1 = @ckey
然后，我修改sSQL参数，运行该存储过程：
sSQL = "exec GetTestDataByKey ’a’"
第二次测试的运行时间是1443ms，与第一次测试中的1494ms记录相比，我们可以认为两者相似。
▲ 测试三：使用ADO的Command对象，脚本文件FirstData2.asp。在第三次测试中，我使用了ADO Command对象，并为存储过程创建了一个参数集合。Listing 2显示了包含ADO代码的函数。我开始了一个新的跟踪，并把结果保存到trace1.trc文件。运行FirstData2.asp，即包含ADO代码和参数集合的.asp脚本，测试结果表明，运行时间在1370ms到1600ms之间。然后，我停止了跟踪。
▲ 测试四：使用索引调整向导。在最后一次测试中，我从Tools菜单启动了Profiler的Index Tuning Wizard（索引调整向导）。使用索引调整向导时，在第一个屏幕上点击Next。在第二个屏幕上，选择正在测试的数据库，然后点击Next。在第三个屏幕上，保持“I have a saved workload file”的选中状态，点击Next。（我们可以把跟踪或SQL保存为workload（工作负载）文件）。在下一个屏幕上，点击“My Workload file”按钮，选择合适的工作负载文件，然后点击Next。在接着出现的屏幕上，只选中正在进行测试的表（miscdata），点击Next。
接下来，索引调整向导运用从数据库跟踪获得的工作负载，分析负载情况。当向导结束分析，它提出了图二显示的索引建议。图二的屏幕还显示了估计可以从索引获得的性能改善程度。其中一次分析显示出性能可以改善大约80%。在性能数据屏幕上，我点击Next。在接下来出现的屏幕上，我点击“Apply Changes”，然后点击Next。在最后出现的屏幕上，我点击Finish使索引建议生效。
当我在新建索引的基础上再次进行测试，结果显示，索引调整向导改善了每一个页面的处理性能。然而，改进程度大约在百分之二十五左右。无论是对于存储过程还是测试一的动态SQL命令，结果都是一样的。CPU的测试数据更令人感兴趣。在修改索引之前，CPU数据的记录范围是从410ms到441ms；修改索引之后，动态SQL的CPU数据下降到了270ms，而对于存储过程，CPU数据下降到了210ms和240ms之间。我们可以看到，添加了一个索引之后，性能有了显著的提高，服务器的CPU负载显著地下降。
【小结】在这篇文章中，我讨论了几个性能分析问题。就象我所做的那样，你可以测试几个页面，得到初始的性能数据；然后，用Profiler深入剖析Web应用，仔细观察服务器的活动情况。例如，在SQL Server处理SQL命令或存储过程的每一个步骤，你可以获取其他各种重要的统计数据。另外请记住，按照索引调整向导的建议创建索引能够显著地提高性能。
