一.分析简单的场景

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

在这里插入图片描述

2.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;
}
3.Controller场景
3.1.先设置5个用户,每隔10秒启动2个用户,到20秒时5个用户的到达集合点,持续运行3分钟

在这里插入图片描述

3.1.1.从图中可以看出运行已用时间为6.58分钟,通过事务为22个,失败事务为0个,错误为0个
3.1.2.事务处理时间最大值是236.035,也就是3.9分钟,最小值是25.702秒,平均值为62.749秒
3.1.3.得出事务处理时间较长,响应较慢,正常打开网页看到全部内容用户能接受的时间就是几秒中
3.1.4.猜测可能是下载页面资源时间过长导致
3.2.设置10个用户,每隔15秒启动4个用户,30秒时用户全部启动,持续运行5分钟

在这里插入图片描述

3.2.1.与5个用户的运行结果相差不大,事务平均响应时间为97.566秒
3.3.设置20个用户,每隔10秒启动5个用户,30秒时用户全部启动,持续运行10分钟

3.4.设置100个用户,每隔10秒启动10个用户,1分30秒时用户全部启动,持续运行10分钟
4.Analysis分析结果
4.1.5个用户的结果分析
4.1.1.概要

在这里插入图片描述

4.1.2.运行vuser

在这里插入图片描述

4.1.3.每秒点击次数

在这里插入图片描述

4.1.4.设置运行vuser与每秒点击次数的关联图

在这里插入图片描述

4.1.5.运行vuser和每秒点击次数的合并图

在这里插入图片描述

4.1.6.吞吐量

在这里插入图片描述

4.1.7.事务

在这里插入图片描述

4.1.8.平均事务响应时间

在这里插入图片描述

4.1.9.windows资源

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

4.1.10.网页诊断

在这里插入图片描述

4.1.11.打开图查看,没有办法评价图片大小是否合理,可以跟开发建议,图片很大是否能修改大小

在这里插入图片描述

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

在这里插入图片描述

4.3.20个用户的结果分析

在这里插入图片描述
在这里插入图片描述

4.3.1.有失败的事务

在这里插入图片描述

4.3.2.事务响应时间明显增大

在这里插入图片描述
在这里插入图片描述

4.3.3.错误统计,具体错误就需要找开发去解决

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

4.3.4.查看吞吐量

在这里插入图片描述

4.3.5.查看本机网络带宽

在这里插入图片描述

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

二.问题总结

在这里插入图片描述

1.从图中可以看出随着运行时间的增长,用户数的增加,运行事务数也增加,
1.1.不过20个用户时出现失败的事务数,平均事务响应时间也越来越大,事务平均值达到159秒,
1.2.2.65分钟,得出事务处理时间较长,响应较慢,正常打开网页看到全部内容用户能接受的时间就是几秒中

1.3.从图中可以看出吞吐量也越来越大,平均吞吐量也越来越大,点击次数也是越来越增多
1.3.1.这些指标是提高但是牺牲一些平均事务响应时间
2.虚拟用户数的增加也导致错误的发生,资源下载超时,服务器过早关闭,SSL链接关闭等问题
3.3次执行过程中有一个js下载时间很长,有一个图片大小为2M多,需要关注
4.window资源没出现瓶颈,不过没监控到linux服务器,以后的工作中会有接触

4.1.监控linux服务器时可以直接通过loadrunner连接服务器添加一些指标去监控
4.2.也可以同步在linux服务器下输入命令去监控,然后到导入到loadrunner中生成报告
5.100个用户执行结果
5.1.执行到最后报错了,由 mdrv 进程终止导致的非正常终止

在这里插入图片描述

5.2.Analysis分析结果

在这里插入图片描述

5.3.其中有个瓶颈是CPU使用率达到100%,这只是本地windows的CPU瓶颈,不是服务器端的瓶颈

在这里插入图片描述

更多推荐