2、客户端监听测试
给测试脚本中添加jp@gc - PerfMon Metrics Collector监听器,然后添加需要监控的服务器资源选项,启动脚本,即可在该监听器界面看到资源使用的曲线变化。如下图所示:
在脚本启动后,即可从界面看到服务器资源使用的曲线变化,Chart表示主界面显示,Rows表示小界面以及不同资源曲线所代表的颜色,Settings表示设置,可选择自己需要的配置。
PS:注意测试脚本需要持续运行一段时间,才可以看到具体的曲线变化,否则ServerAgent端会断开连接!
五、线程组
1、线程数:表示启动的线程数,也就是并发的数量。
2、Ramp-Up Period:表示1秒内启动1个线程,默认为0,表示程序启动后,立即开启1个线程,设置太大或太小都不是很好,设置的最佳值,Ramp-Up Period = 线程数/吞吐量。
3、循环次数:表示每个线程要发送多少次请求。
4、调度器:顾名思义,持续时间如果设置为60,表示持续1分钟,通常循环次数和调度器设置一个即可。
六、添加HTTP请求
一个HTTP请求有着许多的配置参数,下面将详细介绍:
1、名称:本属性用于标识一个取样器,建议使用一个有意义的名称。
2、注释:对于测试没有任何作用,仅用户记录用户可读的注释信息。
3、服务器名称或IP :HTTP请求发送的目标服务器名称或IP地址。
4、端口号:目标服务器的端口号,默认值为80 。
5、协议:向目标服务器发送HTTP请求时的协议,可以是http或者是https ,默认值为http 。
6、方法:发送HTTP请求的方法,可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
7、Content encoding :内容的编码方式,默认值为iso8859
8、路径:目标URL路径(不包括服务器地址和端口)
9、自动重定向:如果选中该选项,当发送HTTP请求后得到的响应是302/301时,JMeter 自动重定向到新的页面。
10、Use keep Alive : 当该选项被选中时,jmeter 和目标服务器之间使用 Keep-Alive方式进行HTTP通信,默认选中。
11、Use multipart/from-data for HTTP POST :当发送HTTP POST 请求时,使用Use multipart/from-data方法发送,默认不选中。
12、同请求一起发送参数 : 在请求中发送URL参数,对于带参数的URL ,jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中,表中的每一行是一个参数值对(对应RUL中的 名称1=值1)。
13、同请求一起发送文件:在请求中发送文件,通常,HTTP文件上传行为可以通过这种方式模拟。/14、从HTML文件获取所有有内含的资源:当该选项被选中时,jmeter在发出HTTP请求并获得响应的HTML文件内容后,还对该HTML进行Parse 并获取HTML中包含的所有资源(图片、flash等),默认不选中,如果用户只希望获取页面中的特定资源,可以在下方的Embedded URLs must match 文本框中填入需要下载的特定资源表达式,这样,只有能匹配指定正则表达式的URL指向资源会被下载。
15、用作监视器:此取样器被当成监视器,在Monitor Results Listener 中可以直接看到基于该取样器的图形化统计信息。默认为不选中。
16、Save response as MD5 hash:选中该项,在执行时仅记录服务端响应数据的MD5值,而不记录完整的响应数据。在需要进行数据量非常大的测试时,建议选中该项以减少取样器记录响应数据的开销。
七、系统吞吐量 QPS(TPS)
系统吞吐量 = 每秒处理的事务数
QPS(TPS)= 并发数/平均响应时间
一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。
八、聚合报告
我认为聚合报告应该是JMeter压力测试软件中最重要的报告。
1. #Samples:样本数,如果你看过上一篇,这个就是前面我们那个公式算出来的结果
(Loop Count(Loop Controler)*Number of Threads*Loop Count(group))
2. Average:平均响应时间。
3. Median:中位数,50%用户响应时间。
4. Line:90%用户响应时间。
5. Min:最小响应时间。
6. Max:最大响应时间。
7. Error%:本次测试中出现错误的请求的数量/请求的总数
8. Throughput:吞吐量,表示每秒完成的请求数。
9. KB/Sec:每秒从服务器端接收到的数据量(只是接收)。
九、Linux查看程序运行情况
1、Top
top命令是Linux下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况,类似于Windows的任务管理器。
top显示系统当前的进程和其他状况,是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户 终止该程序为止. 比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间 对任务进行排序;而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定。
在linux系统中,top命令可谓是分析系统性能最方便的工具,而且top还是个交互式工具;通过top命令可以清楚地了解到正在执行的进程信息包括进程ID,内存占用率,CPU占用率等。其实就跟window的任务管理器类似。
2、查看CPU使用率
sar -u 1 5
表示每1秒采集一次,共采集5次。
这个命令可根据实际线程组中的设置,进行CPU使用率方面的查看。
[root@sss ~]# sar -u 1 5
Linux 3.10.0-957.10.1.el7.x86_64 (izuf633l0ge76tv5mzalpmz) 04/16/2019 x86_64 (1 CPU)
04:56:03 PM CPU %user %nice %system %iowait %steal %idle
04:56:04 PM all 0.00 0.00 0.00 0.00 0.00 100.00
04:56:05 PM all 0.00 0.00 0.00 0.00 0.00 100.00
04:56:06 PM all 0.99 0.00 0.99 0.00 0.00 98.02
04:56:07 PM all 0.00 0.00 0.00 0.00 0.00 100.00
04:56:08 PM all 0.00 0.00 0.00 0.00 0.00 100.00
Average: all 0.20 0.00 0.20 0.00 0.00 99.60
3、查看内存占用情况
free -m
1352/1838即为内存占用。
十、Linux如何统计进程的CPU利用率
Linux的/proc文件系统,可以看到自启动时候开始,所有CPU消耗的时间片;对于个进程,也可以看到进程消耗的时间片。这是一个累计值,可以"非阻塞"的输出。获得一定时间间隔的两次统计就可以计算出这段时间内的进程CPU利用率。
所以,是否存在一种简单的,非阻塞的方式获得进程的CPU利用率? 答案是:“没有”。这里给出一个很恰当的比喻:“这就像有人给你一张照片,要你回答照片中车子的速度一样”。
1、/proc/stat 统计总CPU消耗
计算CPU总消耗可以使用如下shell命令:
cat /proc/stat|grep "cpu "|awk ‘{for(i=2;i<=NF;i++)j+=$i;print "cpu_total_slice " j;}’
cpu_total_slice 19208187744
2、进程消耗的CPU时间片
在proc文件系统中,可以通过/proc/[pid]/stat获得进程消耗的时间片,输出的第14、15、16、17列分别对应进程用户态CPU消耗、内核态的消耗、用户态等待子进程的消耗、内核态等待子进程的消耗(man proc)。所以进程的CPU消耗可以使用如下命令:
cat /proc/9583/stat|awk ‘{print "cpu_process_total_slice " $14+$15+$16+$17}’
cpu_process_total_slice 1068099
3、"非阻塞"的计算进程CPU利用率
从这里也看到,是没有某个时刻CPU利用率的说法的,也就没法获得某个时刻的CPU利用率。这就像物理中的"速度"的概念,没有某一时刻速度的概念,速度一定是一个时间段之内的。那么要"非阻塞"计算某个进程CPU利用率,则需要取两次事件间隔进行计算,这两次事件间隔的操作可以是非阻塞的。计算办法如下:
时刻A,计算操作系统总CPU时间片消耗total_cpu_slice_A;计算进程总CPU时间片消耗;total_process_slice_A ;
时刻B,计算操作系统总CPU时间片消耗total_cpu_slice_B;计算进程总CPU时间片消耗;total_process_slice_B。
B时刻就可以"非阻塞"的计算这段时间进程的CPU利用率了:
100%*(total_process_slice_B-total_process_slice_A)/(total_cpu_slice_B-total_cpu_slice_A)
十一、JMeter使用过程中常见的问题
1、Response Times Over Time中的峰值和聚合报告中的最大值为何不一致?
因为Response Times Over Time中的点是一个时间的概念,表示的是一段时间内的请求的平均响应时间,而聚合报告中的最大值表示的是一个请求的最大响应时间,因此Response Times Over Time的峰值和聚合报告中的最大值不一致。
2、Response Times Over Time图中有多少个点,和请求数有什么关系?
Response Times Over Time中的点是一个时间的概念,在setting中可以设置,每隔500ms记录一个点,这个点就表示这段时间内的请求的平均响应时间。
十二、CPU使用率与CPU空闲时间的关系?
多任务操作对CPU都是分时间片使用的,比如A进程占用10ms,B进程占用30ms,然后空闲60ms,再又是A进程占用10ms,B进程占用30ms,空闲60ms;如果一段时间内都是如此,那么这段时间内的CPU占用率就是40%。
CPU对线程的响应并不是连续的,通常会在一段时间后自动中断线程。未响应的线程增加,就会不断加大CPU的占用。
往期精彩内容:
Ending
Tip:由于文章篇幅有限制,下面还有20个关于MySQL的问题,我都复盘整理成一份pdf文档了,后面的内容我就把剩下的问题的目录展示给大家看一下
如果觉得有帮助不妨【转发+点赞+关注】支持我,后续会为大家带来更多的技术类文章以及学习类文章!(阿里对MySQL底层实现以及索引实现问的很多)
吃透后这份pdf,你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难(但也不简单),扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题,这一套下来p7岗差不多没什么问题,还是希望大家都能拿到高薪offer吧。
面解析(超级详细)]( )
Ending
Tip:由于文章篇幅有限制,下面还有20个关于MySQL的问题,我都复盘整理成一份pdf文档了,后面的内容我就把剩下的问题的目录展示给大家看一下
如果觉得有帮助不妨【转发+点赞+关注】支持我,后续会为大家带来更多的技术类文章以及学习类文章!(阿里对MySQL底层实现以及索引实现问的很多)
[外链图片转存中…(img-GxvjptlH-1718708255030)]
[外链图片转存中…(img-GKOMlqoq-1718708255031)]
吃透后这份pdf,你同样可以跟面试官侃侃而谈MySQL。其实像阿里p7岗位的需求也没那么难(但也不简单),扎实的Java基础+无短板知识面+对某几个开源技术有深度学习+阅读过源码+算法刷题,这一套下来p7岗差不多没什么问题,还是希望大家都能拿到高薪offer吧。