测试目标：
测试过程是否满足以上过程指标及最终的需求指标；
及如何通过结合2者指标评估出被测系统及上线环境的线性对比指标；
最后得到系统的性能、可扩展性、可用性等测试结论。

测试步骤：
1) 基准测试：分步测试。测试结果是一致的且可重现。测试环境一直处在相同的高负载下进行。
2) 容量规划测试：系统测试。容量规划在测试需求阶段就需要从设计获取了，详见附件《性能指标容量规划.DOC》。如果要确定系统的容量，需要考虑几个因素。这些用户中有多少是并发与服务器通信的，其次是，每个用户的"考虑时间"即请求时间是多少，以及本次请求服务通信总响应的时间是多少，等等。通过用户考虑时间+服务器响应时间=场景总运行时间，且通过调整各参数及随机因子（利用"调步"的理念向负载场景中引入更多的随机性），换算出最大及最优同时并发用户数。接着引入ramp-up测试及flat测试不断微调。
3) 峰谷测试：系统测试。峰谷测试通过一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：
第二次高峰是否重现第一次的峰值？
其后的每次高峰是等于还是大于第一次的峰值？
在测试过程中，系统是否显示了内存或GC（内存释放）性能降低的有关迹象？
测试运行（不停地重复"峰值/空闲"周期）的时间越长，系统的性能越被了解。 
4) 渗入测试：系统测试。渗入测试所需时间较长，也叫疲劳测试。渗入测试以2端负载通过低负载/高负载运行较长时间，即运行两次测试，一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。
测试所需指标：
1、 获取各WEB服务的性能指标，包括 WEB SERVER的性能（包括线程数（为了给执行队列决定一个理想的线程数，当队列中所有应用程序都运行在最大负荷的情况下，监视队列的吞吐量。增加线程数，重复负载测试，直到达到最佳的吞吐量。（在某些情况下，增加线程数将产生足够多的上下文转换程序，使得队列中的吞吐量开始减少。））、最大并发数、最优并发数、TPS）；
--最佳线程数（调整并满足既定的配置数，详见2.2硬件环境描述）
--最佳吞吐量 for server (tomcat/sip/oracle)
--响应时间 for case（OSAP/PXYWEB/xxxCOMP/WEB SERVICES）
--最大同时并发用户数 for osap
--最佳同时并发用户数 for osap
--最佳用户数下的TPS for case（OSAP/PXYWEB/xxxCOMP/WEB SERVICES）
2、 能力组件性能
--最大并发用户数下的CPS for case（xxxCOMP）
--最佳线程数（调整并满足既定的配置数，详见2.2硬件环境描述）
--最佳吞吐量 for server (tomcat)
--响应时间 for case（xxxCOMP）
--最大同时并发用户数 for case（xxxCOMP）
--最佳同时并发用户数 for case（xxxCOMP）
3、 应用服务（SIPSVR）的性能指标：
---最佳线程数
---最佳吞吐量 for case5
---CPS for case2/case5
4、 后置指标：
---各服务器的CPU占用百分比（基准测试/容量规划测试/渗入测试）
---各服务器的Memory平均占用比例 （基准测试/容量规划测试/渗入测试）
（例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后到下一阶段。）

容量规划
前提（测试结果有效的先决条件）：
1、 web/sip/oracle/第三方后台服务器配置满足建设方案标准配置或以上；

2、 系统正常工作时，用户访问系统的基本性能需求如下：
1) 软终端用户登录时间<= 3秒
2) WEB终端用户页面初始化操作<= 3秒
3) WEB接入的系统响应时间：在带宽足够的情况下，用户点击访问页面时间不超过3秒，请求提交响应时间最大不超过5秒；
4) 系统一般性操作最长时间<= 2秒
5) 用户操作界面友好，交互性强，在出现错误时，应能显示错误提示信息，并且错误信息能够被用户取消，并恢复界面正常显示。

3、 根据项目一期设计，系统建设要求满足3万用户需求，业务话务模型如下：
1) 点击拨号
按最大CAPS为60计算，普通用户的通话时长为60秒，媒体服务器为主叫放音时长为30秒。
2) 网络传真
按最大CAPS为3计算，每个呼叫时长为120秒，媒体服务器话音提示时长为15秒。
3) Web会议
按最大CAPS为0.2计算，每次会议保持时长为120秒，会议方数为5方，40%用户存在数据协同会议需求。
4) 短信
短信按每秒100条计算。
5) 电话总机
按最大CAPS为0.5计算，每个呼叫时长为90秒。

4、 九的个数和时间之间的对应关系。
可接受的运行时间百分比 每天的停机时间 每月的停机时间 每年的停机时间
95 72.00 分钟 36 小时 18.26 天
99 14.40 分钟 7 小时 3.65 天
99.9 86.40 秒钟 43 分钟 8.77 小时
99.99 8.64 秒钟 4 分钟 52.60 分钟
99.999 0.86 秒钟 26 秒钟 5.26 分钟

5、业务比例选取：
 “xx”平台用户主要针对中小企业用户，按照约有3万企业用户，xx商业客户分类如下：
客户类型 客户员工规模 客户数量 比率
1-2线客户 约3-10人 135万 86%
3-10线客户 约10-100人 19.5万 12%
10线以上客户 约20-500人 2.2万 2%
 按以上比例，3万用户中，2.58万为1-2线用户，3600为3-10线用户，600为10线以上用户。

6、在线使用概况
峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ，如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施进行容量规划，您应当为系统的峰值容量做规划。
描述 值
会话的平均时间 7 分钟(420 秒)
峰值乘数 3x 平均值
每个用户每次访问的请求数 10

7、事务比例选取
对于行业应用，测试数据的准备中最重要的就是事务的选取，以上从业务比例中抽取每个客户类型的事务比例：
比例的分布：
操作 分布权重 发送比例 标准化 每个操作的请求数 每个会话的请求数 
定购(ws)/请求使用 0.10  10*0.1=1 2 1 Ws:canuse
登录 0.10  10*0.1=1 1 2 Login->logout
发送传真 0.20  10*0.2=2 1 3 Osap->pxy->comp->sip
已发/接收传真 0.03  10*0.03=0.3 2 2 Osap->pxy->comp->
发送短信 0.20  10*0.2=2 1 3 Osap->pxy->comp->
已发/接收短信 0.05  10*0.05=0.5 2 2 Osap->pxy->comp->
点击拨号 0.20  10*0.2=2 1 3 Osap->pxy->comp->ctd
发起会议 0.09  10*0.09=0.9 1 3 Osap->pxy->comp->ipunity
定制语音流程 0.03  10*0.03=0.3 1 3 Osap->pxy->comp->->sip
总计 1  10   

其中 分布权重 一栏给出某类操作占总请求数的百分比。
其中 标准化 一栏表示分布权重乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达10。
其中 每个操作的请求数 一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因，有些操作会产生多个请求。
其中 每个会话的请求数 一栏给出了用户在每次会话中发起的对某一操作的请求数量。

8、测试强度估算：
测试强度估算时采用如下假设前提：
*全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；
*采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
按照3万用户每用户每次访问的10请求数，每7分钟一次会话计算，可处理业务约30万笔，每小时处理超过100次请求。其中，假设早上9点及下午15点为高峰期，按照2个小时段的业务处理量估计如下：
10%的业务处理每笔订购业务需对应用服务器提交1（标准化）*10=10次请求；
10%的业务处理每笔登录业务需对应用服务器提交1（标准化）*10=10次请求；
20%的业务处理每笔传真业务需对应用服务器提交2（标准化）*10=20次请求；
20%的业务处理每笔短信业务需对应用服务器提交2（标准化）*10=20次请求；
20%的业务处理每笔呼叫业务需对应用服务器提交2（标准化）*10=20次请求；
9%的业务处理每笔呼叫业务需对应用服务器提交9（标准化）*10=9次请求；
其余11%的业务每笔业务向应用服务器提交1.1（标准化）*10=11次请求。

根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。
每年总的请求数量为：（30*10%*10*2+30*10%*10*2+30*20%*20*2+30*20%*20*2+30*20%*20*2+30*9%*9*2+30*11%*11*2）*2=60+60+240+240+240+48.6+72.6=961.2万次/年。
每天的请求数量为：961.2/200=4.806万次/天。
每秒的请求数量为：（48060*80%）/（8*20%*3600）=38448/5760=6.675次/秒。
正常情况下，应用服务器处理请求的能力至少应达到：6.675次/秒。
某种程度上，可认为请求数量约等于交易数量：
如果再考虑未来几年的交易量的增加（每年增长15％），则可以归纳为：
第一年（万） 第二年（万） 第三年（万） 第四年（万） 合计（万）
30 34.5 39.675 45.627 149.802

同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试

分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu

使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length

通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）

性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •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、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor 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：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.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数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于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’;
2 如果数据的缓存命中率小于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))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
    select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
  内存排序命中率 ：
    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'

1.截取某个字符中的某几位代码：

下面的列子是：截取字符串"ABCDEFG"中,　从第三位开始连续两位的字符，即:CD.

int k;
char  tempstr2[30];
char *strtmp="ABCDEFG";

   for (k=1;k<3;k++)
      {
      strtmp++;
      }
lr_output_message( "strtmp=%s",strtmp);
strncpy(tempstr2,strtmp,2);
lr_output_message( "tempstr2=%s",tempstr2);

2.将某个变量的值赋值给某个参数

下面的列子是：将上段代码中变量tempstr2的值，赋值给参数列表中的参数temp,并且显示出来。
lr_save_string(tempstr2,"temp");
lr_output_message("the velue is:%s",lr_eval_string("{temp}"));

LoadRunner执行的时候随着虚拟用户数的增加，耗用的系统资源也会增加，根据以往的使用经验，在512m的机器上可以模拟500个并发用户，所以请根据运行LoadRunner的机器的性能决定最大的并发用户数，一般来说，只有外网的门户网站才可能达到并发500用户这样的规模，一般的应用系统在100并发用户的情况下就已经是满负载了。

1.在原有参数化文件用记事本打开的时候添加新列（注意在记事本编辑过程中字段内容与内容之间要有间隔符和换行符，间隔符号一般都用逗号，换行符直接回车就行了）。
2.也可以在参数属性中直接添加。

性能测试框架执行步骤：测试启动、测试建模、测试准备、测试执行、测试分析，五个阶段

第一阶段：引入本次性能测试目的，给出测试参考依据，撰写产品测试计划（初稿）

第二阶段：技术调研，比如：产品服务拓扑架构，服务器交互技术，数据存储方式，雏形逻辑调用关系（一般以核心增、删、改、查及异常类）
了解服务器架构（主要用到技术特征）
需要明确：（如
使用LoadRunner作为压力测试工具
使用Web/HTTP WinSock协议开发测试脚本
使用Spotlight 监控数据库
使用Server Monitor监控服务资源
UDI需事先准备全量数据
EAI/ECTIP实时交易需要开发相关挡板程序）
定义测试方案
第三阶段：测试数据建模，如：建立测试数据基础模型，空数据量、1年数据量、3年数据量等
定义基础表单、基础流程（如：控件的数量、控件的大小、流程中节点的个数、条件的复杂程度）
定义基准数据的分布、基准事务的建立、事务的比例关系（百分率、机器人的个数）、场景关系）
第四阶段：测试准备
部署测试环境、明确执行性能测试前各系统参考指标、撰写准备测试报告
第五阶段：测试执行
执行测试、记录测试数据
第六阶段：测试分析

性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •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、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor 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：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.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数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
   4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于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’;
2 如果数据的缓存命中率小于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))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
   内存排序命中率 ：
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

总结了一下在使用LR工具时使用不同的三种方式插入检查点，希望对大家有帮助。

检查点问题前提条件
插入方法1 （如图1） （图1）

在录制过程中选择要添加为检查点的文字，点选工具条上的红框所示图标（图１），即在脚本中加入了相应的检查点函数（文字检查点），当然你也可以通过菜单项NEW　STEP加入文字或者图片检查点（图２），还有一种方式就是根据服务器的响应信息添加检查点（图３），你自己在稍微了解一下图片和文字检查点函数的内容就行了，有问题我们再联系！

插入方法2 （如图2）（图2）

插入方法2 （如图3）（图3）

性能测试注意事项：

1．服务器端和客户端一定要同一个局域网内，否则网络因素会成为性能测试的瓶颈。

2．在性能测试脚本中要注意检查点的设置，否则都不清楚脚本是否真的成功执行操作。

3．设置参数化和关联是性能测试脚本调通的关键。

4．录制脚本时通常会包括一些think time,因此在回放脚本时，注意在runtime setting中设置忽略think time，否则会影响测试数据的准确性，如：响应时间的准确性。

5．尽量每个页面设置一个transcation,否则不知哪个页面最慢。

6．运行性能测试时在runtime setting中关闭日志功能，调试脚本时可以打开日志功能。

7．性能测试前的数据准备很重要：比如：系统数据库存在60000个用户和系统数据库存在60个用户，分别在两种情况下执行登陆性能测试，性能测试的结果也不会一样的。

8．在性能测试时用户登陆的用户名和密码，每个用户尽可能不要一样！

由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别
性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的
性能测试指标的来源:
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）
主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。
BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）；
HTTP观点:
1、 负载测试是正常情况下持续的加压；
2、 压力测试是直接加压达到一个极限值。 
大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。
性能测试要点：
   1、 性能测试是在功能测试完成之后进行。
　　2、 性能测试计划、方案一般与测试用例统一在一个文档里。
　　3、 测试环境应尽量与用户环境保持一致。
　　4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。
　　5、 性能测试的重点在于前期数据的设计与后期数据的分析。
　　6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）

Action()
{

iter=iter+1;
lr_vuser_status_message("We are on iteration #%d",iter);
lr_think_time(3);
return 0;
}
在init中：int iter=0;
这样在Controller中可以看到点Vuers可以看到：
We are on iteration #5.说明它进行到第5次迭代了。

运行方案时，默认情况下，脚本会复制到Vuser组计算机的临时目录中。这样，Vuser组负载生成器便可以从本地而不是通过网络访问脚本。
当然你也可指示Controller将脚本存储在共享网络驱动器上，请参见“执行路径转换”。

LR有5种目标类型：并发的用户数，每秒点击数，每秒事务数，每分钟页面数，你想达到的事务响应时间。
1：如果你知道了用户总数，则选》并发的用户数
2：如果你知道了服务器处理能力就选》每秒点击数，每秒事务数，每分钟页面数
3：如果你期望得到完成一个事务所要的响应时间》你想达到的事务响应时间。例如你不想让登录时间超过5秒，则设定最大接受事务响应时间为5秒来看一下有多少用户登录成功。

controller中设置了100个用户并发，可是运行的时候，每次只初始化50个用户。
进入controller后在Tools->options->Run-time setting中可以自己设置每次最多初始化的虚拟用户数。