一键复制
在日常的学习、工作、生活中，肯定对各类范文都很熟悉吧。相信许多人会觉得范文很难写？下面是小编帮大家整理的优质范文，仅供参考，大家一起来看看吧。
loadrunner测试结果分析详解篇一
今年十月份我到北京跟张坤学习性能测试知识，共花了三个星期学习loadrunner。以下是我的学习小结。
一． 什么是loadrunner loadrunner是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟多个用户实施并发负载测试及实时性能检测的方式来确认和查找问题，能对整个企业架构进行测试。
二． loadrunner的优点
1.轻松创建虚拟用户：通过记录下业务流程转为测试脚本，在机器上产生多个用户访问，减少负载测试需要的硬件和人力资源。
2.创建真实的负载：可以通过controller设定负载方案，如定义用户在什么时候访问系统以产生负载，所有用户同时执行一个动作来模拟峰值负载情况等。3.实时监测器：可以实时显示交易性能数据（如响应时间）和其他系统组件如数据库，网络等的实时性能。
4.分析结果以精确定位问题所在：loadrunner能收集汇总所有测试数据，提供高级的分析和报告工具。
三． loadrunner的安装与使用
1.安装过程详见上传的loadrunner使用手册，在此不再详细介绍。2.具体使用：
点击file新建录制文件，也可以点击下面的new快捷键进行新建。使用file新建，会弹出协议选择窗口，选择新的单协议脚本（new single protocol script）的web(http/html)项，确定即可（选择web项是因为我们测试的是web应用）。接着会弹出开始录制的设置项，需要写入录入系统的地址，点击确定后就会根据录入地址展现系统页面，开始录制脚本，出现小工具条：
第一个按钮为录制键 第二个为回放脚本键 第三个为停止录制键 第四个为暂停录制键 第五个为编译脚本键
第六个为创建新的action键。lr的录制脚本分为三个部分，vuser_init、vuser_end和 action。脚本循环执行时，只执行一次vuser_init和vuser_end，而多次循环action部分。比如录制投保业务时，登陆系统部分放入vuser_init，退出登陆放到vuser_end，中间的投保操作放到action中，则循环执行时就会登陆一次投保系统开始反复执行投保操作直到结束退出系统。
第七个为用来改变录制的options设置按钮
第八个和第九个为插入事务的起始点和结束点键，结合起来构成一个完整事物，用来衡量服务器的性能。比如录制脚本过程中，投保系统的查询投保单号操作，可以在输入完查询信息后点击查询按钮前插入事务的起始点，查询出数据后插入事务的结束点，这样在运行测试脚本时，loadrunner在运行到该事务时，便会计算出这个查询操作所花时间，便于衡量服务器执行查询操作的性能。
第十个为插入集合点键，可用于衡量在加重负载的情况下服务器的性能。比如要验证系统是否能承受100人同时进行报案操作，便可在脚本录入过程中，点击报案确认键操作前插入集合点，这样当脚本运行到集合点时，loadrunner会让100个虚拟用户同时点击报案确认按钮（如果有的用户还没运行到集合点，先到用户要等未到用户一起操作）进行报案，从而达到测试目的。
最后一个为设置验证点键，在创建事物后，设置一个验证点可以用来确认事物执行是否成功。比如进行查询事务操作时，lr只要检测到网页的响应，就认为事务pass,而不管显示页面内容是否正确。因此为了检查web服务器返回的网页是否正确，可以插入text/image检查点，验证网页上是否存在指定的text或image。
设置验证点时，如果我们验证的文本内容是中文，有时会返回无法找到验证内容的报错信息，而页面显示又是正确的，出现问题的原因可能是因为lr对中文的支持部好，尽量选择验证信息为数字或字母；也可能是设置问题，可以尝试将tools->recording options->http properties下的advanced选项里设置支持utf-8，再检查开发人员有没有设置支持中文。
录制结束后，先点击保存脚本，同时为脚本命名。然后编译脚本，看是否存在语法错误，编译成功后，即可回放，看录制脚本是否成功。
loadrunner录制得到的脚本基本没有错误，不像robot会有录入数据的缺失，只是会录入一些非录入系统的网页信息，根据地址可以识别并删除掉。
四． loadrunner脚本录制学习小结
nner录制脚本，主要是为了进行压力测试，所以跑流程时，跑了主要流程即可，也就是系统必须的信息录入就可以了。nner的脚本运行过程中，只能用于一次业务办理的数据需要做参数化，如车辆车架号，车牌，报案号等，以免出现重复投保或报案无法立案现象，不能继续进行下去。参数化步骤：
1）将需要做参数化的数据右键点击，选择replace with a parameter,进行设置。2）在弹出编辑框里，设置易懂的参数名称，再点击properties进行属性设置。3）点击create table 按钮，生成参数表格，再点击edit with notepad按钮，即可在记事本里添加新的参数，添加完后再次回车（不回车可能最后条数据读取不到）关闭，参数化操作完成。
4）使用ctrl +h键可以找到替换同样的需要参数化的数据。
3.脚本跑流程过程中，因为业务运转，前面生成的投保单要接着进行提交核保业务，而每次生成的投保单号不一样，用于进行提交核保的单号也要与之前的保持一致，因此需要做关联处理，读取到生成的新投保单号给提交核保流程。关联步骤：
1).查找关联数据第一次出现的位置，判断该数据是由什么函数返回的。
2).在树形结构里点击返回该数据值的函数，看它的server response信息，用复制的关联数据进行查找它的返回语句，找到区分度明显的语句（不一定要是第一个返回语句），然后使用web_reg_save_param函数进行关联。
注：关联函数一定要写在第一个返回该数据值的函数前。
3).web_reg_save_param(const char *paramname, , last);函数的第一个参数是用来对关联数据进行定义的，取名最好可读性强；第二个参数是用来标识关联数据在返回语句里的具体位置的，写出该数据的左右边界，程序才能识别；last表示属性列的结束。比如办理理赔业务的流程号，在服务器的返回语句里是：
做关联为：
web_reg_save_param(“logflowid”，“lb=name=flowid type=”hidden“ value=”，“rb=>”，last);定义的参数名就叫logflowid,表示流程号，易于明白；左边界从name取就可以标识了，也可取长点或短点，只要能区分；右边界只有>，写上就好；最后写上last。
在定义的左右边界中，如果有双引号，在脚本中是需要转义的，因为双引号在c中是有意义的，这里只要表示语句信息，加上右斜杠。尖括号直写。
左右边界也需要用双引号括起来。定义好的参数写在程序中，需要在加上单尖括号：swflogflowid={logflowid} 五． 脚本执行过程中的报错处理
_init.c(3051): error-26377: no match found for the requested parameter “proposalno”.check whether the requested boundaries exist in the response , if the data you want to save exceeds 256 bytes, use web_set_max_html_param_len to increase the parameter size [msgid: merr-26377] _init.c(3051): web_submit_data(“”)highest severity level was “error”, 4312 body bytes, 258 header bytes [msgid: mmsg-26388]
两个错误一起出现，出错语句都是在关联函数下的提交数据函数位置，但是具体出错有可能是：
1).关联函数左右边界没写对，所有信息都要用字符输入，不能是中文或其他。
2).在关联函数确认写对的情况下，看提交数据函数中的业务设置，比如有可能是因为保单查询语句，设置的查询时间是过去的时间，新生成的投保单当然查不到，这样程序也会报这样的错。
nner 执行理赔的立案处理，录制好脚本后，回放，报错：
脚本日志信息提示：
.c(400): error-26366: “text=立案信息提交成功” not found for web_reg_find [msgid: merr-26366] .c(400): web_submit_data(“”)highest severity level was “error”, 4424 body bytes, 258 header bytes [msgid: mmsg-26388] 脚本执行过程停止在立案信息提交页面，错误原因：数据问题，可能是有的应该变化的信息没有变。
在该流程中，一个报案号只能做一次立案，而初始脚本没有设置参数、关联，使用保单号进行查询，错误被掩盖。在立案系统中，一个保单号可以重复报案，但是一个报案号只能一次立案，要跑通流程，需要先将这一保单再重复报案，得到新的报案号。
六． 性能测试的场景设置
脚本录制完毕后，接着准备测试场景。1.首先准备测试数据。比如车险投保，需要投保人和车架号信息来唯一标识一辆被保车，因此就需要将投保人和车架号做参数化处理，编辑文本框录入大量数据让脚本唯一读取：
1）.录入投保人参数，车架号参数，过程同脚本录制的参数化处理
2）.因为投保人和车架号一起生成一条投保数据，可设置车架号随投保人参数一起读取，设置步骤为：
投保人文件存放路径--file path
投保人参数数据读取方式
脚本按列名读取参数，每行数据读取一次，每次循环取一次新值。接着设置车架号参数信息：
车架号参数读取文件路径设为和投保人文件路径一样
脚本按列名读取参数，行号选择和读取的投保人数据同一行
这样得到所需的投保单生成参数数据
2.设置测试场景
点击tools->create controller scenarios,弹出场景类型选择框：
录入需要的虚拟用户数，选择生成结果存放路径和组名。确定后进入具体设置页面：
quantity表示虚拟用户个数，group name为组名。
1).设置运行时间选项run – time settings
选择循环次数run logic->iteration count,设置循环10次，虚拟用户数为之前设置的5人，则预计一共可生成50张投保单。
设置思考时间，思考时间通常是录制脚本过程中，填写页面信息花费的时间，选择忽略项，节省跑脚本的时间。
设置网络连接时间，点击网络协议项internet protocol 的options键，将弹出页面里的http-request connect timeout和 http-request receive timeout的数值改为1000。使得能在网络状况不太好的情况下向服务器发送接收数据。
2).设置edit schedule
选择虚拟用户加载方式：
可以一次加载所有用户，也可以按需要设置，一秒加载一个用户或其他。
选择结束方式：
当选择一秒加载一个用户时，结束设置为直到跑完所有脚本停止执行。如果选择选择一次加载所有用户可以选择运行多少时间后停止和不停止选项。
这些设置完成后，一次测试场景布置完成。可以进行基线检查或单点并发测试。
七． 性能测试步骤
一）.除测试工具外性能测试必备的系统及业务知识
1、熟悉保险行业业务特点，有助于与开发和客户讨论需求，制定测试用例；
2、熟悉系统的实现特点，开发实现方式，有助于选择程序处理复杂、消耗系统资源的用例点；
3、熟悉数据结构，了解数据存储规则，对脚本调试、数据准备、测试执行和监视都有帮助；
4、熟悉系统所使用的数据库、操作系统、中间件的监视和性能问题查看，有助于测试监视和发现问题；
5、熟悉系统架构及系统集成方式，有助于分析及明确定位性能问题。
二)性能测试执行过程 1.基线检查
1).目的：验证环境是否可用；
验证脚本是否能在场景正常执行。
2).方法：1个人单独循环5次--没有其他人干扰，干净的环境
3).结果：一般一个事物的响应时间超过3秒就可能存在问题，要提报开发人
2.单点并发
1).目的：为了快速的发现问题，如多进程的锁机制，看是否相互间有影响。2).方法：一般是10人或20人执行10到15分钟，执行过程忽略思考时间。
忽略思考时间可以减少客户端时间，加快向服务器传送数据速度，很大程度上增大了服务器的压力，20个人单点并发的压力就相当于200人正常执行带给服务器的压力。
3).单点测试的数据可以用来进行混发测试，但是有可能单点测试的数据不足以进行混发，需要自己再准备足够的数据。
3.方案测试--混发测试
1).目的：模拟生产环境
2).方法：执行1小时左右，加上思考时间
八．资源监控及调优
性能测试执行过程中，需要监控系统各项资源，看是否能满足用户实际需要，如内存使用，sql server等，结合lr生成的分析报告，分析系统哪里可能存在问题，需要改进，进行调优，这也是我之后要接着进行学习的地方。
1.学习使用weblogic，了解weblogic常配参数的意义。通过weblogic自身的监控台，可以了解到目前的jvm的大小、数据库连接池的使用情况以及目前连接的客户端数量以及请求状况等等。
2.学习oracle使用，熟悉它的体系结构，尤其是oracle10里 的awr，awr能采集与统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题。
3.需要继续学习lr的理论知识和实际操作，参考书籍《web性能测试实战》、《软件性能测试过程详解与案例剖析》
loadrunner测试结果分析详解篇二
性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。
分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（sql语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。• 分段排除法 很有效
分析的信息来源：
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：•error: failed to connect to server “10.10.10.30:8080”: [10060] connection
•error: timed out error: server “10.10.10.30” has shut down the connection prematurely
分析：
•a、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
•b、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是weblogic中的server元素的acceptbacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•c、数据库的连接
（1、在应用服务的性能参数可能太小了
2、数据库启动的最大连接数（跟硬件的内存有关）)
2error: page download timeout(120 seconds)has expired
分析：可能是以下原因造成•a、应用服务参数设置太大导致服务器的瓶颈
•b、页面中图片太多
•c、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么ok。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：unix资源监控中指标内存页交换速率（paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。windows资源监控中，如果processprivate bytes计数器和processworking set计数器的值在长时间内持续升高，同时memoryavailable bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统cpu利用率;
内存不够出错(out of memory errors)
处理器：unix资源监控（windows操作系统同理）中指标cpu占用率（cpu utilization），如果该值持续超过95%，表明瓶颈是cpu。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于sql server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。windows资源监控中，如果systemprocessor queue length大于2，而处理器利用率（processor time）一直很低，则存在着处理器阻塞。
cpu资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
cpu空闲时间为零(zero percent idle cpu)
过高的用户占用cpu时间(high percent user cpu)
过高的系统占用cpu时间(high percent system cpu)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘i/o：unix资源监控（windows操作系统同理）中指标磁盘交换率（disk rate），如果该参数值一直很高，表明i/o有问题。可考虑更换更快的硬盘系统。windows资源监控中，如果 disk queue length的值很高，而page reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
i/o资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘i/o的时间所占的百分率太高(large percentage of time waiting for disk i/o)太高的物理i/o速率:large physical i/o rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但cpu却空闲(large run queue with idle cpu)
4．数据库服务器：
sql server数据库：sqlserver资源监控中指标缓存点击率（cache hit ratio），该值越高越好。如果持续低于80%，应考虑增加内存。如果full scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及sql查询是否可以被优化。number of deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。lock requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
oracle数据库：如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加
shared_pool_size的大小。
快存（共享sql区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins)from v$librarycache;
select(sum(gets-getmisses))/sum(gets)from v$rowcache;
自由内存：select * from v$sgastat where name=’free memory’;如果数据的缓存命中率小于0.90，那么需要加大db_block_buffers参数的值（单位：块）。缓冲区高速缓存命中率：
select name,value from v$sysstat where name in('db block gets’,'consistent gets','physical reads');
hit ratio = 1-(physical reads /(db block gets + consistent gets))如果日志缓冲区申请的值较大，则应加大log_buffer参数的值。
日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = 'redo log space requests';如果内存排序命中率小于0.95，则应加大sort_area_size以避免磁盘排序。
内存排序命中率 ：
select round((100*)/decode((+), 0, 1,(+)), 2)from v$sysstat a, v$sysstat b where ='sorts(disk)' and ='sorts(memory)'
注：上述sql server和oracle数据库分析，只是一些简单、基本的分析，特别是oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。
说明：
以上只是个人的体会和部分资料的整理，并不代表专家之言。算抛砖引玉，有不同看法和更深入的分析的，希望大家勇要发言，以推动我们国内的性能测试工作。
loadrunner测试结果分析详解篇三
本次通过loadrunner录制sqlserver介绍一下如何测试一个sql语句或存储过程的执行性能。主要分如下几个步骤完成：
第一步、测试准备
第二步、配置odbc数据源
第三步、录制sql语句在sql server查询分析器中的运行过程
第四步、优化录制脚本，设置事务
第五步、改变查询数量级查看sql语句的性能
第六步、在controller中运行脚本
下面开始具体的介绍：
测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装sql server数据库服务端及客户端，也可以确定一台装好的sql server服务器。
接下来，准备测试数据：对数据库测试时我们要考虑的不是sql语句是否能够正确执行，而是在某数量级的情况下sql语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某sql语句的执行效率。在查询分析器中运行如下脚本：
--创建测试数据库
create database loadrunner_test;
use loadrunner_test
--创建测试数据表
create table test_table
(username varchar(50),sex int,age int,address varchar(100),post int)
--通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了
declare@iint
set@i=0
while@i<1000//循环1000次，可以根据测试数据情况改变插入条数
begin
begin tran t1
insert into test_table(username,sex,age,address,post)values('户瑞海'+cast(@i as varchar),@i-1,@i+1,'北京市和平里'+cast(@i as varchar)+'号',123456);
if @@error <> 0
begin
rollback;
select @@error
end
else
begin
commit;
set@i=@i+1
end
end
好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置odbc数据源，为了能让loadrunner能够通过odbc协议连接到我们建立的sql server数据路，我们需要在本机上建立odbc数据源，建立方法如下：
控制面板—性能和维护—管理工具—数据源（odbc）--添加，在列表中选择sql server点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成odbc的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。
配置好odbc数据源后就要录制sql语句在查询分析器中的执行过程了：
1、打开loadrunner，选择odbc协议
2、在start recording中的application type 选择win32 application；program to record中录入sql server查询分析器的路径“..”
3、开始录制，首先通过查询分析器登录sql server，在打开的查询分析器窗口中输入要测试的sql语句，如“select * from test_table;”
4、在查询分析器中执行该语句，执行完成后，结束录制
好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我qq，我把脚本发给你们），通过这些语句，我们可以看出，登录数据库的过程、执行sql语句的过程。
接下来，我们来优化脚本，我们分别为数据库登录部分和执行sql语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下：
action()
{double trans_time;//定义一个double型变量用来保存事务执行时间
lr_start_transaction(“sqserver_login”);//设置登录事务的开始
lrd_init(&initinfo, dbtypeversion);//初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）
lrd_open_context(&ctx1, lrd_dbtype_odbc, 0, 0, 0);
lrd_db_option(ctx1, ot_odbc_ov_odbc3, 0, 0);
lrd_alloc_connection(&con1, lrd_dbtype_odbc, ctx1, 0 /*unused*/, 0);
………………
trans_time=lr_get_transaction_duration(“sqserver_login”);//获得登录数据库的时间lr_output_message(“sqserver_login事务耗时 %f 秒”, trans_time);//输出该时间
lr_end_transaction(“sqserver_login”, lr_auto);//结束登录事务
lr_start_transaction(“start_select”);//开始查询事务
lrd_cancel(0, csr2, 0 /*unused*/, 0);
lrd_stmt(csr2, “select * from test_table;rn”,-1, 1, 0 /*none*/, 0);//此句为执行的sql lrd_bind_cols(csr2, bcinfo_d42, 0);
lrd_fetch(csr2,-10, 1, 0, printrow24, 0);
……………..trans_time=lr_get_transaction_duration(“start_select”);//获得该sql的执行时间
lr_output_message(“start_select事务耗时 %f 秒”, trans_time);//输出该时间
lr_end_transaction(“start_select”, lr_auto);//结束查询事务
优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。
接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有mercury 授权的sql server用户license，在运行该脚本时回报错，提示“you do not have a license for this vuser contact mercury interactive to renew your license.”我们公司穷啊买不起loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！
最起码在vugen中运行该脚本我们可以得到任意一个sql语句及存储过程的执行时间，如果我们测试的b/s结构的程序，我们也可以通过html协议录制的脚本在controller中监控sql server服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了。
loadrunner测试结果分析详解篇四
loadrunner性能测试 1.什么是性能测试
软件的功能：对一个软件基本功能能够实现，比如：银行卡能够正常转账成功（用户数=1）软件的性能：要求软件性能更好，一般关注多用户的使用情况，软件的响应时间。响应时间例子：登录一个软件，点击“登录”按钮时，多久能够显示成功登录的页面。
性能问题: 1． 每秒平均浏览量：2200次/秒
浏览量（pv，page view）：即页面访问量或点击量，用户每次刷新即被计算一次 购票申请：20万张/秒以上
自身设计浏览量100万次/小时 浏览量280次/秒
2.响应时间的358原则：
3秒之内，客户比较满意 5秒之内，客户可以接受 8秒之内，客户可以忍受 大于8秒，无法忍受
3.一般进行性能测试之前，要对系统尤其是数据库进行备份
负载测试是一种
正常 的测试（在正常测试的指标下测出最大的负载量）
指标或者某种资源达到某种指标，比如响应时间达到多少，比如cpu负载100%等
压力测试和负载测试二者的区别：
负载测试强调系统在正常工作情况下的性能指标
压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点
影响系统性能的主要因素
（1）硬件： cpu,内存，硬盘，网卡及其他网络设备【最好解决】（2）操作系统（3）网络
（4）中间件（又叫应用服务器），web服务器（5）数据库服务器（6）客户端
（7）变成语言，程序实现方式，算法【最难解决】
客户端=服务端（web服务器）=应用服务器=数据库服务器
性能测试主要关心两个部分：web服务器和应用服务器。客户端向服务器发送请求
服务器端向客户端返回应答（响应response）
性能测试的常用术语： 并发（concurrency）：所有用户在同一时刻（一个时间点，可以精确到毫秒级）做同一件事情或操作，一般针对同一类型的业务
例如：在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交 做并发的测试就称为“并发测试”。【发测试不包含睡眠时间】 在线（online）：多用户在一段时间内对系统执行操作【包含睡眠时间】
并发测试与在线测试对系统的压力不同，一般来讲并发测试的压力和在线测试的压力的比值是10:1。例如：200用户并发测试相当于2000用户在线测试。
并发测试一定是多用户。
请求响应时间
指从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在一些工具中，请求响应时间通常被称为ttlb 即“time to last byte”，意思是从开始发送第一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或者“毫秒”
再复杂的响应时间都可以分为3段：请求的响应时间=客户端的响应时间+网络的响应时间+服务器的响应时间
一般测试放在内网里，带宽，网络不会成为瓶颈。只用分析客户端的响应问题和服务器的响应问题。一般客户端的响应很少有问题，一般只分析服务器响应问题即可。
事务响应时间：用户完成某个具体事务（如跨行取款事务）所需要的时间。事务可能包含多个请求。比如点击“登录”按钮，到登录进页面。
事务的响应时间和请求响应时间的区别？
一个事务包含一个或多个请求（一般，一个请求指的是一个http请求）。
点击率：
每秒钟用户向web服务器提交的http请求数。---点击率越大，对服务器的压力也越大
---注意：点击不是指鼠标的一次“单击”操作。因为在一次“单击”操作中，客户端可能向服务器发出多个http请求（比如跳转页面需要更新展示图片等）。
点击量的计算：假如单击“登录”按钮，请求一个页面登录后的欢迎页面中包含3个图片，则每个图片都需要重新发送一个http请求，所以，单击鼠标一次产生的http请求总数为4=1（登录请求）+3（图片请求）点击率=点击量/时间
吞吐量：
用户在任意给定一秒从服务器端获得的全部数据量，单位是字节 吞吐量/传输时间=吞吐率
吞吐率很重要，反应了服务器的处理速度和性能，也是衡量网络性能的重要指标。tps（事务数/秒）
在性能测试过程中，要监控服务器系统的各项资源情况，比如：cpu，内存，磁盘及网络等情况。
吞吐率和点击率的区别：
吞吐率：指服务器每秒处理的数据量。反应了服务器的处理能力，吞吐率越大，服务器处理能力越强。
点击率：客户端每秒向服务器发送请求的数量。反应了服务器的压力，点击率越大，服务器的压力越大
吞吐率受点击率影响，也受服务器性能的限制。
完美的吞吐率是：在带宽充足的情况下，吞吐率随着点击率的增加而增加。
资源利用率
指对不同的资源系统的使用程度，包括web服务器，操作系统，数据库服务器，网络，硬件，是测试和分析瓶颈的主要参数
-如：服务器cpu利用率，磁盘利用率等
它是分析系统性能指标进而改善性能的主要依据，因此是web性能测试工作的重点。
性能测试的策略（即方法）：重点测试方法：基准测试，并发测试，综合场景测试，疲劳强度测试，极限测试，递增测试
基准测试：一般做的是单用户测试（benchmark testing）
----指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。
----目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。
并发测试：就是多用户的并发测试某个测试点。并发测试对系统要求比较严格，因为要模拟一个瞬间压力。并且要忽略系统的睡眠时间（思考时间）。
递增测试：
a）指每隔一定时间段（如5秒，10秒）加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。原因：所有用户（5000）共同登陆可能会导致系统压力过大，进而影响到后面关心的测试点（buy）的性能，导致关心的测试点结果不准确，所以采取递增，分散一下前面的压力，使系统关心的测试点能够正常的测试。（这里是递增着登陆）b）测试一个测试点（如：购票），先测试单用户，再测试20用户，40用户等情况，有利于分析，也称为递增测试。（这里是递增着全套测试）
综合场景测试【重难点】：
通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。
如10%的用户执行浏览首页，50%的用户执行查询订单，40%的用户执行订购机票，最大限度地模拟系统的真实场景，使用户预知系统投入使用后的性能水平。没特别指明的话，一般都是指在线的。
login不适合放在综合场景中运行。
综合场景：号称能最真实的模拟实际的生产环境。如测试时间为50分钟，则综合场景中的每个脚本都是在循环执行。所以综合场景中不宜加入login测试点，因为不能真实模拟实际的生产环境。
疲劳强度测试：是一种特殊的强度测试（压力测试）。指在一定的压力下（如：相同的用户数）长时间（疲劳）对系统进行测试，并监控服务器的各项资源情况。如：7x24小时,24小时（如移动电信银行的服务器）。测试其服务器的稳定性：指长时间的运行过程中，系统的各项资源及时间等指标表现是否正常。
内存泄露：系统的服务器内存都被占用，而没有释放。导致系统没有可用内存。
内存泄露测试：通过lr监控时查看具体的几项指标，或者通过其它的专门内存泄露检测工具测试。
数据容量测试：查看系统服务器能否实现大数量下使用情况，系统的各项资源表现情况。如：200g，或者3个t。
极限测试：也叫“摸高测试”，测试系统的极限，如系统最大能承受的用户数，吞吐量等。
虚拟用户：virtual users 控制台：controller 分析工具：analysis
loadrunner的三大组件：
虚拟用户脚本生成器（virtual user generator）---creat/edit scripts【generator：生成器】 压力调度控制台（controller）---run load tests 压力结果分析器（analysis）---analyze test results
qtp（功能自动化的工具）和lr（性能测试工具）的区别： qtp关心的是功能方面，lr关心的是性能方面。
qtp关心界面的控件属性（对象，对象的属性，属性值等）等，lr关心的是客户端和服务器之间往来的数据包。
lr的工作原理：
录制时，lr记录客户端和服务器二者之间的所有对话（数据包），形成脚本，回放时，lr模拟真实的客户端，向服务器发送请求。并验证服务器的响应。
lr是怎么记录下数据包的：（1）基于局域网的广播原理。【这种用的很少】（2）基于一种嗅探原理sniffer。【目前在用的方式】
虚拟用户脚本生成器：是用来生成脚本的
lr的常用术语：
虚拟用户（virtual user 【简称vu】）：在场景中，loadrunner用vu代替实际用户。vuser模拟实际用户执行操作。一个场景可以包含几十，几百甚至几千个vuser。（每个虚拟用户是一个进程或者线程，一般用的是线程）
vuser脚本（virtual user script）：用于描述vu在场景中执行的操作。（记录的客户端发送的请求。）
事物（transaction）：为度量服务器的性能，需要定义事务。事务表示要度量的最终用户业务流程或操作。
为何要定义事务：因为脚本中将关心的操作（如购票）定义为一个事务，则结果报告中（analysis）就会返回事务的响应时间。不关心的操作就不需要定义成事务。
场景（scenario）：场景是一种文件，用于根据性能要求定义在每一个测试回话运行期间发生的事件。模拟真实环境中，用户运行的情况。【将脚本放到控制台去运行（包括设置各种参数）】
综合场景：将不同的脚本，至少3个放到控制台去共同运行一段时间。具体定义见ppt。
测试注意：
----设置ie（清楚浏览器缓存）：进入工具internet选项常规设置每次访问此页面时检查
----lr中修改参数：进入controllerruntime settingtnternet protocol proxy，选择no proxy。
jojo /bean
lr基本测试流程：
制定性能测试计划（部分）创建测试脚本编译，运行测试脚本【vug】创建场景运行，监控场景，收集数据【con 控制台】生成测试报告，分析测试结果【analysis】
最好用英文命名
小技巧： 弹出结果
日志文件
transaction 事务
将一个操作设置成事务的目的：获取操作的响应时间（在analysis报告里）
在带宽充足的情况下，完美的吞吐率应该随着点击率的升高而升高。反过来，当服务器压力过大服务器处理能力不足时，吞吐率会随着点击率的增高而保持恒定或者降低，那么点击率也会受到相应影响而变慢。
即吞吐率和点击率是相互影响的。
脚本生成器可以模拟1个用户，多用户一定要用控制台来实现。（控制台就是来生成管理多用户的。）
基准测试是单用户测试，可用脚本生成器（生成的调试结果是没有响应时间的），但是也还是需要控制台。因为结果要写到报告里。（结果生成器analysis得出单用户测试的结果，比如响应时间等等）
疲劳测试和综合场景测试的区别就是时间的长短，疲劳测试运行的时间会长一些。
只要业务逻辑不变（操作不变），则不需要重新调试脚本，回归测试中可以直接利用原来脚本。
调试脚本时请频繁保存副本，因为lr回退键效果不是很好。
脚本必须现在脚本生成器进行运行，执行通过将脚本放入控制台，在控制台执行完毕后生成结果报告
总的吞吐率
服务水平等级协议
报告中事务响应时间的标准方差值：越趋近于0，说明系统越稳定（每一项事务的响应时间非常相似）
90percent：表示90%的事务都可以在该响应时间内完成。代表一个大多数情况。
http状态码： 200表示成功
4xx表示客户端的失败 5xx表示服务器的失败
当场景设定的duration时间结束时，所有的虚拟用户需要运行完当前的transaction以及action再结束。
基准测试执行方法
单用户执行脚本操作1分钟 单用户执行脚本操作5次
b/s脚本必须要有登陆，有退出（否则假退出其实链接还没断开，会影响测试结果）
replay log：脚本执行日志 recording log：录制时的日志
generation log：所有客户端和服务器二者之间的对话
快捷键：
ctrl+g
go to line 跳到某一行
跳到对应的日志
基准测试：单用户测试。3.4 1.7 1.8 1.6 为了规避第一次测试的不准确性，则有两种测试方法：（1）设置循环5次（n次）
run-time setting 循环5次，或者持续运行1分钟。（取平均值）run logic：循环次数----设置为5 pacing：两次循环之间的步长值（时间间隔）----随机值2-4秒 think time：ignore（忽略思考时间），因为对结果没什么影响
pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值
基准测试单用户对服务器压力不大，一般可以ignore think time。
监控资源：监控服务器的资源
客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。
（2）持续运行1分钟
当duration和run_time setting中循环（run logic）都有值的话，duration的优先级比较高【二者循环的位置都为action】 run logic：循环次数----设置为1
pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值 基准测试单用户对服务器压力不大，一般可以ignore think time。监控资源：监控服务器的资源
客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。
并发测试执行方法： 脚本添加集合点
在控制台设置并发策略
注意：refresh中有两个选择，看情况使用。
脚本和控制台的run-time setting都设置的话，哪个优先级高？控制台的优先级高！脚本中的run-time setting 何时使用？运行脚本的时候使用
并发测试有两个步骤：
1）脚本中加并发点（即集合点）
2）在控制台设置：5个虚拟用户（vu），可以设置递增（不设也可），设置并发策略。
run-time setting---忽略休息时间，因为需要瞬间压力。
loadrunner测试结果分析详解篇五
loadrunner性能计数器分析总结
2009-12-02 14:48
memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 ram 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
available mbytes:可用物理内存数.如果available mbytes的值很小（4 mb 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
physical disk % disk time
physical disk queue length
例如，包括 page reads/sec 和 % disk time 及 queue length。如果页面读取操作速率很低，同时 % disk time 和 queue length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 physical disk
sec/transfer 和 memory pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
page faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
cache bytes：文件系统缓存（file system cache），默认情况下为50%的可用物理内存。如iis5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 memory available bytes 和 memory
committed bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 processprivate bytes、processworking set 和processhandle count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 memorypool nonpaged bytes、memory pool nonpaged allocs 和 process(process_name)pool nonpaged bytes。
pages per second :每秒钟检索的页数。该数字应少于每秒一页。
process：
%processor time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
page faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
inetinfo:private bytes:此进程所分配的无法与其它进程共享的当前字节数
量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%processor time:如果该值持续超过95%，表明瓶颈是cpu。可以考虑增加一个处理器或换一个更快的处理器。
%user time:表示耗费cpu的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%privileged time：（cpu内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和“physical disk”参数值一直很高，表明i/o有问题。可考虑更换更快的硬盘系统。另外设置tempdb in ram，减低“max async io”，“max lazy writer io”等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 server work queues queue length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% dpc time:越低越好。在多处理器系统中，如果这个值大于50%并且processor:% processor time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
thread
contextswitches/sec:(实例化inetinfo 和dllhost 进程)如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
physical disk:
%disk time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%disk time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在windows 2000 的命令行窗口中运行diskperf-yd。若数值持续超过80%，则可能是内存泄漏。
queue length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个raid disk实际有多个磁盘。
average disk read/write queue length:指读取(写入)请求(列队)的平均数。disk reads(writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
average disksec/read: 指以秒计算的在此盘上读取数据的所需平均时间。average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。network interface：
bytes total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
sqlserver性能计数器：
access methods(访问方法)用于监视访问数据库中的逻辑页的方法。
.full scans/sec(全表扫描/秒)每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及s q l查询是否可以被优化。
.page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。buffer manager(缓冲器管理器)：监视 microsoft® sql server? 如何使用： 内存存储数据页、内部数据结构和过程高速缓存；计数器在 sql server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 i/o。监视 sql server 所使用的内存和计数器有助于确定： 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，sql server 必须从磁盘检索数据。是否可通过添加更多内存或使更多内存可用于数据高速缓存或 sql server 内部结构来提高查询性能。
sql server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 i/o 会耗费大量时间。尽可能减少物理 i/o 可以提高查询性能。
.page reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 i/o 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
.page writes/sec(.写的页/秒)每秒执行的物理数据库写的页数。
.buffer cache hit ratio.在“缓冲池”（buffer cache/buffer pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 sql server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 sql server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。.lazy writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。cache manager(高速缓存管理器)对象提供计数器，用于监视 microsoft® sql server? 如何使用内存存储对象，如存储过程、特殊和准备好的 transact-sql 语句以及触发器。
.cache hit ratio(高速缓存命中率，所有cache”的命中率。在sql server中，cache可以包括log cache，buffer cache以及procedure cache，是一个总体的比率。)高速缓存命中次数和查找次数的比率。对于查看sql server高
速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
latches(闩)用于监视称为闩锁的内部 sql server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
.average latch wait ti m e(m s)(平均闩等待时间(毫秒))一个sql server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
.latch waits/sec(闩等待/秒)在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
locks(锁)提供有关个别资源类型上的 sql server 锁的信息。锁加在 sql server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它(x)锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。
.number of deadlocks/sec(死锁的数量/秒)导致死锁的锁请求的数量
.average wait time(ms)(平均等待时间(毫秒))线程等待某种类型的锁的平均等待时间
.lock requests/sec(锁请求/秒)每秒钟某种类型的锁请求的数量。
memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 sql server 实例所使用的内存有助于确定：是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，sql server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 sql server 内部结构来提高查询性能。
lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
total server memory：sql server服务器当前正在使用的动态内存总量.监视iis需要的一些计数器
internet information services global:
file cache hits %、file cacheflushes、file cache hits
file cache hits %是全部缓存请求中缓存命中次数所占的比例，反映了iis 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而file cache hits是文件缓存命中的具体值，file cacheflushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较file cache hits 和file cache flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考iis 的设置
objectttl、memcachesize、maxcachefilesize）
web service:
bytes total/sec:显示web服务器发送和接受的总字节数。低数值表明该iis正在以较低的速度进行数据传输。
connection refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
not found errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（http状态代码404）
监视内存计数器（补充）
要监视内存不足的状况，请从以下的对象计数器开始：
内存信息：
memory available bytes
memory pages/sec
memory available bytes
如果您怀疑有内存泄露，请监视 memoryavailable bytes 和 memory
committed bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 process private bytes、process working set 和process handle count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 memory pool nonpaged bytes、memory pool nonpaged allocs 和 process(process_name)pool nonpaged bytes。
cpu信息：
processor % processor time 获得处理器使用情况。
也可以选择监视 processor % user time 和 % privileged time 以获得详细信息。
server work queues queue length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。
system processor queue length 用于瓶颈检测
通过使用 process % processor time 和 process working set
process % processor time过程的所有线程在每个处理器上的处理器时间总和。
硬盘信息：
physical disk % disk time
physical disk queue length
例如，包括 page reads/sec 和 % disk time 及 queue length。如果页面读取操作速率很低，同时 % disk time 和 queue length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
physical disk % disk time
physical disk queue length
例如，包括 page reads/sec 和 % disk time 及 queue length。如果页面读取操作速率很低，同时 % disk time 和 queue length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
请观察 processor interrupts/sec 计数器的值，该计数器测量来自输入/输出
(i/o)设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。
physical disk disk reads/sec and disk writes/sec
physical disk current disk queue length
physical disk % disk time
logicaldisk % free space
测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。
可能需要观察的附加计数器包括 physical disk sec/transfer、 bytes/transfer，和 disk bytes/sec。
sec/transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。
也可以查看 bytes/transfer 的值。值大于 20 kb 表示该磁盘驱动器通常运行良好；如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 disk sec/transfer 时间，因为随机传送需要增加搜索时间。
disk bytes/sec 提供磁盘系统的吞吐率。
决定工作负载的平衡
要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 physical disk % disk time 计数器，该计数器显示驱动器活动时间的百分比。如果 % disk time 较高（超过 90%），请检查 physical disk current disk queue length 计数器以查看正在等待磁盘访问的系统请求数量。等待 i/o 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到 2 倍。
尽管廉价磁盘冗余阵列(raid)设备通常有多个主轴，大多数磁盘有一个主轴。硬件 raid 设备在“系统监视器”中显示为一个物理磁盘；通过软件创建的 raid 设备显示为多个驱动器（实例）。可以监视每个物理驱动器（而不是 raid）的 physical disk 计数器，也可以使用 _total 实例来监视所有计算机驱动器的数据。
使用 current disk queue length 和 % disk time 计数器来检测磁盘子系统的瓶颈。如果 current disk queue length 和 % disk time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。
