LoadRunner进行性能测试过程讲解分解.ppt

三、场景 －－场景设置 加入oracle指标计数器 ◆将oracle拖入显示窗口 三、场景 －－场景设置 ◆连接oracle，其中server name是你本机配置的服务名，登入用户可以是system也可以是其他用户 三、场景 －－场景设置 ◆加入关注的计数器，注意选择obiect时选择第三项，否则得不到数据。至于这一项具体的内容，介绍一个网址，大家可以去看看：/hawem/blog/item/ec7fc2f92bcfe55a242df23e.html 这里面有一些常用统计的解释，内容较多不在此列出。 三、场景 －－场景设置 比如加入physical reads 三、场景 －－场景执行 在场景执行的过程中，可以看到执行的信息，如果发现有大量事务报错 或 执行时间特别长，可以终止本次执行；但要根据报错信息判断是否因为系统无法支撑本次并发数导致的，如果是，则要减少用户数后再次执行；如果不是，查找错误原因，解决错误之后再次执行。 对同一类场景，要多执行几次，找出出现次数较多的那个响应时间。 另外，在监控linux系统的性能指标时，可以用vmstat、iostat命令来获得一些信息供以后分析。 三、结果分析 －－结果摘要 分析结果摘要中包括了本次测试结果大概的信息，我们关注比较多的有： ◆执行的场景的路径，保存结果的路径，执行了多长时间 ◆最大并发用户数 ◆事务的通过数，失败数，终止数 ◆事务的响应时间 ◆返回的http状态代码 ，主要看有没有错误信息（参考附件“返回http代码状态”） 三、结果分析 －－加入新图表 加入新图表，通常有操作系统相关、数据库相关、事务相关、网页细分相关 三、结果分析 －－事务分析 查看事务是否通过及响应时间 ◆在事务摘要中，看要测试的事务（比如接单事务）是否全部运行通过。如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的； ◆如果加有检查点的事务，看检查点事务是否全部运行成功；如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的； ◆事务执行后可以在数据库中看到相应的变化，最好查看数据库里面的记录的变化内容及数量，是否与前面的事务执行通过数一致。如果是一致的才算是场景真的执行通过了； ◆事务全部通过了，它的平均响应时间才有意义。查看它的平均响应时间是否在我们的要求内，适当增减并发用户数再执行。 三、结果分析 －－事务分析 事务执行未通过，考虑： ◆是否需要更改场景运行的设置（比如接受HTTP请求响应时间默认是120秒超时，如果需要可以改大一点） ◆负载过大，服务器的系统资源（CPU、内存、磁盘等）不足以支持事务执行；这种情况下，要分析是哪种系统资源不足，然后再分析是硬件瓶颈引起的还是由程序引起的。 ◆负载不大，服务器所有资源充足，但仍有事务未运行成功。这种情况主要考虑是否是被测程序的问题。 事务响应时间过长，同上面的第二和第三点 三、结果分析 －－获取常用性能指标 目前在做性能测试的时候，如果测的是windows系统，一般就只用LR监控就可以了，在设置场景时加入windows相关的计数器；如果测试的是linux系统，则还要用linux的命令（常用的有vmstat、iostat），因为LR里面包含的linux相关的计数器比较少，所以用这些命令做为补充。 三、结果分析 －－常用指标分析 LR指标－CPU Utilization(CPU利用率) 一般认为，CPU连续长时间处在95％（90％）以上，则可能是CPU的瓶颈。 ◆“长时间”究竟定义为多长？以前我认为是5秒，因为经常说用户能忍受的响应时间是5秒，连续5秒CPU都占用95％以上，那事务响应时间很有可能就在5秒以上了；后来做了几次测试之后我发觉