LoadRunner基本使用流程及结果分析(图文)
性能测试结果分析基础教程(图文并茂)
Loadrunner 结果分析基础教程Loadrunner测试结果分析如下：1、Analysis Summary 结果及分析如下：此次测试我用了30个用户，但有1个failed，5个error。
所以实际参与测试的虚拟用户总共有24个。
其中，总的吞吐量为3448691bytes，平均吞吐量为12965bytes，总的请求量为720，平均每秒请求量为2.707。
从该图可以看出，该系统存在一定的问题，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。
2、Running Vusers结果及分析如下：通过上面图形结果可知，在刚开始虚拟用户为0，30秒多时突然达到24个用户访问，一直到4：17秒将为16个用户，到4：25秒24个用户全部访问结束。
3、Hits perSecond结果及分析如下：该图为每秒点击次数，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
由上图不难看出：分别在0s、40s、1：12s三个时间点点击数最大，到后面基本处于稳定状态。
4、Througput结果分析如下：该图和上面第三个图恰好相识，由上图不难看出：分别在0s、40s、1：12s三个时间点吞吐量最大，到后面基本处于稳定状态，这不难看出是由于点击数引起的。
5、Transaction Summary 结果分析如下：有该图不难看出，该系统处于正常运行状态。
6、Vuser Summary 结果分析如下：由该图不难看出：虚拟用户通过的占96%，失败的占4%。
所以，从整体上来看，大部分用户运行正常。
7、Error Statistics 结果分析如下：从上图不难看出:错误数据只有1个，所以也可以看出系统基本运行正常。
LoadRunner使用手册
LoadRunner基本测试过程由以下四个步骤组成：1. 步骤一：创建脚本∙通过录制应用程序中典型最终用户执行的操作来生成虚拟用户（Vuser），将该用户的操作录制到自动虚拟用户脚本中，以便作为负载测试的基础。
2.步骤二：设计场景3.步骤三：运行场景∙运行用来模拟真实用户执行操作的脚本，并可以通过让多个虚拟用户（Vuser)同时执行这些操作来在系统中创建负载。
4.步骤四：分析结果∙提供包含深入的性能分析信息的图和报告。
使用这些图和报告，可以标识应用程序中的瓶颈，并确定需要对系统进行哪些更改来提高系统性能。
通过LoadRunner模拟登陆，设计操作路径新建录制1.1.新建录制信息1、新建一个web[Http]的[图-1.1][图-1.1]2、开始录制操作，先输入要录制的网页路径[图-2.1]、[图-2.2][图-2.1][图-2.2]3、开始录制4、录制结束,录制结束后点击停止[红色方框圈着的] [图-4.1][图-4.1]5、输入访问人数[图-5.1]6、运行[图-6.1]7、查看1人操作的时间[图-7.1]8、保存录制结果[图-8.1]9、新建运行[图-9.1][图-9.1] 10、选择要进行分析的文件[图-10.1]、[图-10.2][图-10.1][图-10.2]11、设置测试的方式[绝对并发，相对并发] [图-11.1][图-11.1]a)设置Edit Scheduleb)开始：Load all Vusers simultaneously 同时一起执行。
i.Load all Vusers simultaneously:绝对并发,同时访问。
ii.Start：每次执行访问的次数Vusers every:相隔多少时间iii.c)执行：Run until completion 直到完成i.d)结束：直到结束才停止。
i.12、设置访问用户数[图-12.1] 或[图-12.2] 都可以设置[图-12.1][图-12.2]13、点击运行分析[图-13.1][图-13.1]14、点击后，弹出对话框，询问，是否将结果默认保存到xx路径，最好自己设置，以便于查找测试结果信息。
使用loadrunner的流程
使用LoadRunner的流程1. 简介LoadRunner是一款性能测试工具，可用于模拟并测试不同负载条件下的应用程序性能。
它是业界著名的性能测试工具之一，广泛应用于软件开发和测试领域。
本文将介绍使用LoadRunner的基本流程，包括录制脚本、编辑场景、运行测试、分析结果等内容。
2. 录制脚本使用LoadRunner进行性能测试的第一步是录制脚本。
脚本录制是指将用户对应用程序的操作记录下来，以便后续可以回放并模拟用户行为。
下面是录制脚本的步骤：•打开LoadRunner，选择录制模式。
•配置录制设置，包括选择要录制的应用程序和协议。
•启动录制，执行各项操作，包括登录、浏览网页、提交表单等。
•停止录制，保存录制的脚本文件。
3. 编辑场景录制完脚本后，需要对场景进行编辑和定制，以模拟真实的负载条件。
场景是指一组用户行为的集合，可以包括不同的用户数量、并发用户数量、用户的思考时间、延迟时间等。
以下是编辑场景的步骤：•打开LoadRunner，选择编辑场景模式。
•导入录制的脚本文件。
•配置场景参数，包括虚拟用户数量、并发用户数量、需模拟的业务负载等。
•设置运行时的动态参数，如需替换用户名、密码等敏感信息。
•配置场景的持续时间、循环次数、运行模式等。
4. 运行测试场景编辑完成后，可以开始运行性能测试。
在运行测试期间，LoadRunner将模拟多个虚拟用户并发访问目标应用程序，记录并分析系统的性能指标。
以下是运行测试的步骤：•打开LoadRunner，选择运行测试模式。
•配置测试设置，包括选择要运行的场景、设置测试目标等。
•启动测试运行，观察测试运行的过程。
•监控系统性能指标，如响应时间、吞吐量、服务器负载等。
5. 分析结果性能测试完成后，需要对测试结果进行分析。
LoadRunner提供了丰富的分析工具，用于分析各项性能指标，找出性能瓶颈并提供建议。
以下是分析结果的步骤：•打开LoadRunner的分析工具。
Loadrunner分析结果图说明
Loadrunner分析结果图说明1、Running Vusers图使用Vuser 图可以确定方案，执行期间Vuser 的整体行为。
X 轴表示从方案开始运行以来已用的时间。
Y 轴表示方案中的Vuser 数。
Vuser-Rendezvous 图主要反映Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.图中可以看到在1分4秒的地方50个用户全部集中到达集合点，持续了5分48秒开始释放用户，整个过程持续了6分钟。
2、Hits per Second图“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
3、Throughput图“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
X 轴表示从方案开始运行以来已用的时间。
Y 轴表示服务器的吞吐量（以字节为单位）。
“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
4、Transaction Summary图对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
5、Average Transaction Response Time图“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
loadrunner结果分析图
使用LoadRunner Analysis进行分析的第一步是看测试结果的综合报告，当发现事务运行不正常时，才需要进行更深入的分析。
1、用户事务分析。
“用户事务”主要针对业务而言，一个“用户事务”通常由一个或一系列的用户操作组成。
Action是用户的一系列操作的组合；Transaction是用户的某一具体的动作。
与用户事务相关的图表有以下8个（1）事务综述图（Transaction Summary）通过此图可以看出每个事务在测试时间内分别通过（Pass）和失败（Fail）了多少（2）事务平均响应时间分析图（Average Transaction Response Time）此图显示测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析应用系统的性能走向；另外还可以统计出测试场景运行时间内各事务的最大值、最小值、平均值等信息。
（3）每秒通过事务数分析图（Transactions per Second）TPS图显示在场景运行的每一秒中，每个事务通过的数量，通过它可以确定系统在任何给定时刻的实际事务负载；可以将TPS图与平均事务响应时间图进行对比，以分析事务数目对执行时间的影响。
（4）每秒通过事务总数分析图（Total Transactions per Second）“每秒通过事务总数分析”图显示场景运行时，在每一秒内通过的事务总数。
如果系统性能稳定，在同等压力下，此图应该接近直线，而不是逐渐倾斜。
与TPS相比，“每秒事务总数”关注服务器整体处理事务的情况，是宏观概念。
（5）事务性能摘要图（Transaction Performance Summary）“事务性能摘要”显示方案中所有事务的最小、最大和平均时间，可以直接判断响应时间是否符合用户的需求。
可以通过网页细分方法来分析某些响应时间长的事务。
（6）事务响应时间与负载分析图（Transaction Response Time Under Load ）这个分析图是“正在运行的虚拟用户”图和“平均事务响应时间”图的组合。
loadRunner使用图解
loadRunner测试基本步骤：录制脚本→脚本调试→加载脚本、设置参数→压力测试→测试完成、生成测试报告以某系统签到签退测试脚本为例：1、录制脚本运行loadRunner，点击create/edit scripts图1.1 loadRunner主界面—录制脚本点击弹出窗口的new Vuser script…按钮图1.2 脚本选择界面弹出选择脚本协议窗口，默认为web(HTTP/HTML)，签到签退功能测试的类型是web，所以直接点击ok图1.3 协议选择界面在下图中，在URL Address中输入测试入口地址，输入完成后，点击ok，开始录制图1.4 录制脚本参数设置界面图1.5 点击ok后，弹出窗口，开始录制图中红色标识部分为脚本录制的阶段。
一共有三个：vuser_init（初始化）、Action （动作）、vuser_end（结束）以签到压力测试为例，我们要测试的动作为签到，初始化为用户登录，结束可以为用户退出，也可以为用户点一下其它按钮。
输入用户名、密码，登录系统图1.7 脚本录制—初始化阶段，登录完成。
登录完成后，初始化阶段完成，经红色标识部分调整为Action，开始动作部分—签到。
调整为Action后，开始录制动作。
在门户首页点击个人事务，点击签到点击确认，完成签到动作签到动作完成后，Action录制完成。
结束动作开始。
我们以点击一下沟通中心作为整个操作的结束，沟通中心页面加载完成后，点击结束按钮，脚本录制完成。
2、脚本调试点击下图中标识的按钮，进行脚本回放图2.1 脚本回放再次点击回放按钮图2.2 脚本回放完成后，再次点击回放按钮图2.3 系统参数比较先选择下方的参数，然后点击correlate，参数比较完成图2.4 点击查看脚本按钮图2.5 脚本中记录用户名密码参数的位置图2.6 脚本中其它参数的位置找到脚本中记录用户名密码参数的位置，替换为另一个人如wujq（将脚本中zhouyun 改为wujq），找到其它需要修改的参数的位置，如empId，由于员工一天只允许签一次到，所以empId是必须修改的（wujq的员工id为7942，所以empId部分修改为7942）。
LoadRunner的基本使用
LoadRunner 8.1基本使用刘韧LoadRunner 8.1基本使用 (1)一、脚本录制 (2)二、脚本回放 (3)三、创建负载测试 (4)四、场景设置 (4)五、主要数据图表的介绍 (5)一、脚本录制在LoadRunner中要进行脚本的录制，点击“开始”—>“程序”—> “Mercury LoadRunner”—> “LoadRunner”，进入LoadRunner页面，在负载测试选项卡下选择“Create/Edit Scripts”(创建/编辑脚本)，如图1-1所示。
图1-1在进行脚本录制之前首先要选择适合的协议（比如Web应用程序的选择Web （HTTP/HTML）），如图1-2所示。
图1-2在选择适合的协议之后会自动弹出录制对话框或者点击Start Record按钮同样可以进入录制对话框，在对话框中可以指定目标URL、Aplications的类型（一种是Internet类型，一种是Win32类型）、录制到指定的Action，如图1-3所示。
图1-3在录制过程中或者是录制结束之后可以通过/对录制的脚本添加事务开始/结束标志，通过添加集合点（集合点的添加只能在Action中进行，vuser_init和vuser_end 中不能添加集合点）。
添加事务可以使得每一个操作的事务响应时间更加准确的获得用户每一个操作的响应时间。
添加集合点可以帮助我们生成有效可以控制的并发操作。
集合点如果添加在事务中，那么等待的时间也将记录在事务响应时间中，这样会引起事务响应时间的不正确。
二、脚本回放脚本录制结束之后将视图切换至Tasks点击脚本回放可以回放刚才脚本录制的过程，如图2-1所示。
图2-1脚本回放之后将脚本保存，以便运行场景的时候加载。
三、创建负载测试在脚本回放成功之后，就可以创建负载测试了，点击RUN LOAD TEST如图3-1所示，进入Controller界面。
图3-1四、场景设置点击Run LoadTest之后将会出现一个新建场景对话框，其中Manual Scenario为手工场景，Goal-Oriented Scenario为目标场景，如图4-1所示。
4、LoadRunner基础培训之结果分析
Analysis ：常见图介绍_ Hit per Second
Analysis ：常见图介绍_ Hit per Second
Page Download Time Breakdown页面下载时间细分图 图中详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表1所示。通过这些指
标的数据，我们可以轻易的判断是哪个时间慢。
Analysis ：常见图介绍_ Page Download Time Breakdown
Page Download Time Breakdown页面下载时间细分图组成，表1：
Analysis ：常见图介绍_ Throughput
Throughput吞吐量图 显示方案运行过程中服务器上每秒的吞吐量。吞吐量的单位为字节，表示 vuser在一秒时
间内从服务器获得的数据量。借助此图可以依据服务器吞吐量来评估vuser产生的负载量，可 以和平均事务响应时间图对照观察，以查看吞吐量对事务性能产生的影响。
一般CPU使用率要求不超过75%，物理内存使用率不超过70%。(n_Html
Analysis ：报告类型介绍_SLA
Analysis ：报告类型介绍_自定义
Loadrunner：常见问题汇总
Thanks!
Analysis ：常见图介绍_ UNIX Resources
UNIX Resources系统资源图 系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机
器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存 使用率，以及处理器队列长度。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、录制脚本1. 打开2. 点击编辑脚本1/ 463. 点击按钮新建脚本4. 弹出对话框，选着web（http/html）2/ 465. 输入网址，点击ok3/ 466. 录制脚本，录制结束后，点击一下按钮停止录制7. 录制成功后，生成脚本8. 点击如下按钮回放脚本4/ 469. 点此按钮，可新增action10. 点此按钮可以进行录制和回放设置5/ 466 / 4611. 弹出的参数话界面 一般回放设置下这里就好12. 点击图中图表设置参数化13. 弹出的设置界面，主要设置红色区域的几个地方14. 下图按钮为脚本调试7/ 4615. 下图按钮为设置时间的其实点和结束点的按钮16. 下图两个按钮分别为与hp质量管理工具ALM连接按钮和创建场景按钮8/ 4617．插入事件，分别表示时间的开始和结束9/ 46事件插入成功：18. 设置集合点10/ 46二、创建场景1.在vugen中点击图中按钮创建场景2.弹出编辑框，设置场景，设置完成后点击ok第一个是目标场景第二个是手动场景其中手动场景可以设置加载虚拟用户数11/ 463.双击这里选着加压主机12/ 464.选择主机ip，和系统13/ 465.点击ok关闭对话框图中红色区域是选着场景执行方式：模拟真是环境还是基于时间表模拟14/ 466.下图中：1）Schedule by选项表示加载方式，基于脚本还是基于组2）Run mode表示加载模式：分别表示模拟真实情况和还是基于场景15/ 4616 / 467. 双击下图红色区域，可选着加压力度8.双击红色区域，可设置压力下完运行时间17/ 4618 / 469. 双击下面红色的内容，可以选着虚拟用户停止的模式10.弹出设置选项框，可以选着停止的方式全部一下停止每多少时间停止多少个的方式停止19/ 4620 / 4611. 点击run ，来到执行界面12. 在执行界面点击start Scenario,开始跑场景21 / 4613. 下图为执行过程中14. 场景跑完后显示如图界面：其中右边红色区域是运行过程中监控服务器的资源占用率等等的一些信息，在左边还可以添加或查看其他的一些图标15.点击下面按钮也能添加加压主机22/ 4616.经15后，弹出选项框，点击add可以输入主机信息23/ 4617.设置ip欺骗24/ 4625/ 46三、结果分析1.点击下面按钮，进入分析结果界面2.分析界面如下：26/ 463.点击这里的图表可以查看各结果的，然后对结果进行分析27/ 464.按照如下操作可以增加新的图表28/ 4629 / 465. 右键图表选着合并图表，可以合并分析6. 合并后的图表具体实例教你如何做LoadRunner结果分析LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.30/ 462.系统资源:2.1 硬件环境：CPU：奔四2.8E硬盘：100G网络环境：100Mbps2.2 软件环境：操作系统：英文windowsXP服务器：tomcat 服务浏览器：IE6.0系统结构：B/S 结构3.添加监视资源下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。
Mercury Loadrunner Analysis 中最常用的5 种资源.1. Vuser2. Transactions3. Web Resources4. Web Page Breakdown31/ 465. System Resources在Analysis 中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点“open graph”即可.打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.其余的看不看都可以.都不是很重要.【注】51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
内容导航32/ 464.分析集合点在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous(集合点) 图.图1可以看到大概在3 分50 的地方30 个用户才全部集中到start 集合点,持续了3 分多,在7 分30 的位置开始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.33/ 46图2上面图2 是集合点与平均事务响应时间的比较图.注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3:34/ 46图3图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.35/ 46图4这张图包括Average Transaction Response Time 和Running Vuser 两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)36/ 46图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.Transaction Response Time(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.37/ 46很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.38/ 46一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.在select page to breakdown 中选择页面.见图.39/ 46在Select Page To Breakdown 中选择后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.40/ 46也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.%processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。
如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%DPC time(processor_total)::越低越好。
在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。