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