Loadrunner性能测试（六）：脚本开发、场景设计、指标分析

分析一个简单的场景：

分别模拟5个、10个、20个、100个虚拟用户进入csdn网站首页。

csdn网站首页：

image.png

vugen脚本为：

Action_rendezvous()
{
    
    web_set_sockets_option("SSL_VERSION", "TLS1.1");
    web_add_cookie("Hm_ct_6bcd52f51e9b3dce32bec4a3997715ac=6525*1*10_19814196820-1526528487575-539618; DOMAIN=www.csdn.net");

    web_add_cookie("uuid_tt_dd=10_19814196820-1526528487575-539618; DOMAIN=www.csdn.net");

    web_add_cookie("dc_tos=ptyfw6; DOMAIN=www.csdn.net");

    web_add_cookie("dc_session_id=10_1526528487575.516753; DOMAIN=www.csdn.net");

    web_add_cookie("Hm_lvt_6bcd52f51e9b3dce32bec4a3997715ac=1561970163; DOMAIN=www.csdn.net");

    web_add_cookie("TY_SESSION_ID=47e865f3-1857-4c8d-8791-ab14094f7f4f; DOMAIN=www.csdn.net");
    
    //设置集合点
    lr_rendezvous("homepagerendezvous");
    
    //开始事务
    lr_start_transaction("homepage");
    
    web_url("www.csdn.net", 
        "URL=https://www.csdn.net/", 
        "TargetFrame=", 
        "Resource=0", 
        "RecContentType=text/html", 
        "Referer=", 
        "Snapshot=t109.inf", 
        "Mode=HTML", 
        EXTRARES, 
        "Url=/images/icon_close_big.png", ENDITEM, 
        "Url=/images/is_top_big.png", ENDITEM, 
        "Url=/favicon.ico", "Referer=", ENDITEM, 
        "Url=/images/icon_close_hover_big.png", ENDITEM, 
        LAST);
    

    //结束事务
    lr_end_transaction("homepage", LR_AUTO);

    
    return 0;
}

Controller场景：
1、先设置5个用户，每隔10秒启动2个用户，到20秒时5个用户的到达集合点，持续运行3分钟：

image.png
从图中可以看出运行已用时间为6.58分钟，通过事务为22个，失败事务为0个，错误为0个，事务处理时间最大值是236.035，也就是3.9分钟，最小值是25.702秒，平均值为62.749秒，得出事务处理时间较长，响应较慢，正常打开网页看到全部内容用户能接受的时间就是几秒中，猜测可能是下载页面资源时间过长导致。

2、设置10个用户，每隔15秒启动4个用户，30秒时用户全部启动，持续运行5分钟：

image.png

与5个用户的运行结果相差不大，事务平均响应时间为97.566秒。

3、设置20个用户，每隔10秒启动5个用户，30秒时用户全部启动，持续运行10分钟。
4、设置100个用户，每隔10秒启动10个用户，1分30秒时用户全部启动，持续运行10分钟。

Analysis分析结果：
1、5个用户的结果分析：
概要：

image.png
运行vuser：
image.png
每秒点击次数：
image.png
设置运行vuser与每秒点击次数的关联图：
image.png
运行vuser和每秒点击次数的合并图：
image.png
吞吐量：
image.png
事务：
image.png
平均事务响应时间：
image.png
windows资源：
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
网页诊断：
image.png
打开图查看，没有办法评价图片大小是否合理，可以跟开发建议，图片很大是否能修改大小：
image.png

2、10个用户的结果分析：
每秒点击次数、吞吐量、事务摘要、平均事务响应时间、网页诊断与5个用户的结果分析相差不大，windows资源有些变化：

image.png

3、20个用户的结果分析：

image.png
image.png

有失败的事务：

image.png
事务响应时间明显增大：
image.png
image.png

错误统计，具体错误就需要找开发去解决了：

image.png
image.png
image.png
image.png
查看吞吐量：
image.png
查看本机网络带宽：
image.png

平均吞吐量是403568Byte/s，查看本机网络带宽是144Mbps=14410001000/8=18000000Byte/s
吞吐量远小于18000000Byte/s，所以吞吐量没有达到瓶颈。

问题总结：

image.png
1、从图中可以看出随着运行时间的增长，用户数的增加，运行事务数也增加，不过20个用户时出现了失败的事务数，平均事务响应时间也越来越大，事务平均值达到了159秒，2.65分钟，得出事务处理时间较长，响应较慢，正常打开网页看到全部内容用户能接受的时间就是几秒中。
从图中可以看出吞吐量也越来越大，平均吞吐量也越来越大，点击次数也是越来越增多，这些指标是提高了但是牺牲了一些平均事务响应时间。
2、虚拟用户数的增加也导致错误的发生，资源下载超时，服务器过早关闭，SSL链接关闭等问题。
3、3次执行过程中有一个js下载时间很长，有一个图片大小为2M多，需要关注。
4、window资源没出现瓶颈，不过没监控到linux服务器，以后的工作中会有接触（监控linux服务器时可以直接通过loadrunner连接服务器添加一些指标去监控，也可以同步在linux服务器下输入命令去监控，然后到导入到loadrunner中生成报告）。

100个用户执行结果：
执行到最后报错了，由 mdrv 进程终止导致的非正常终止。

image.png

Analysis分析结果：

image.png

其中有一个瓶颈是CPU使用率达到了100%，这只是本地windows的CPU瓶颈，不是服务器端的瓶颈：

image.png