性能测试

基于java应用服务器的性能监控图表分析

LensNews
一、Jmeter工具接口性能测试统计图表
1、线程数:100,Period:1,持续:5分钟,无集合点
分析:通过dstat命令发现,CPU使用率持续达到90%以上,但没有出现CPU等待的情况,因此可以分析,100个并发的时候,服务器就已经负载过高了。
但是CPU还可以应急的过来业务请求,但如果在增加压力的话,将有可能出现等待的情况。并且通过top命令可以发现,MySQL和Java进程占用CPU过高的使用率


2、线程数:200,Period:1,持续:5分钟,无集合点
分析:加大并发数为200后,对比并发数100的情况,反而吞吐量比之前100的降低了,并且响应的请求数也降低了。由此可见,200个并发已经超过了系统负载范围。
并且出现CPU等待的情况,因此可以推断CPU此时已经负载过高,处理不过来。


3、线程数:500,Period:1,持续:5分钟,无集合点
分析:第一次和第二次请求总数都在16000多,并且相差不大,并且平均响应时间都在27000毫秒左右,可以断定,500个并发的时候,最高可以通过16000多个事务。
每秒的吞吐量在50.0个请求左右。通过观察服务器负载情况,均都已超出负载范围,并且CPU出现等待处理的情况。


二、zabbix监控平台服务器监控图表分析(示例)
1、CPU使用率,包括系统和用户
说明:6次测试,分别为100,200,500,500,200,100个并发,可以发现,CPU使用率100>200>500,
通过下图的黄色区域可以分析,当并发数超出100的时候,CPU出现等待的情况,导致CPU能够处理的业务量降低,从而导致并发数为200和500时,吞吐量比100个并发的时候更低。

2、cpu突发。包含 context switches per second 进程线程切换 ,interrupts per second 每秒的中断次数。
说明:6次测试,依次为100,200,500,500,200,100个并发,CPU突发曲线图,跟CPU使用率一样,线程切换以及中断次数也是100>200>500

3、网络流量
说明:网络流量跟吞吐量保持一致,从jmeter图表报告中可以查看,分别是100>200>500,但是出网带宽比进网带宽要高跟多。

三、nmon工具服务器监控图表分析(示例)
1、SYS_SUMM:显示当前服务器的总体性能情况
Avg disk tps during an interval:显示采集间隔内磁盘平均I/O次数
Max disk tps during an interval:显示采集间隔内磁盘最大I/O次数
CPU%:所有CPU总体占有率变化情况
IO/sec:磁盘IO的变化情况,每秒钟输出到物理磁盘的传输次数
图表分析:下面4个图表分别进行的是:100,200,500,50的用户并发,磁盘读操作在正常范围内,但CPU使用率基本都在80%以上,但这种情况下CPU也能够及时响应过来。
有可能是因为添加了集合点导致的。

2、CPU_ALL:显示当前服务器所有CPU在采集时间段内的利用率,按时间及User%、System%、Wait%显示
User% : 显示在用户模式下执行程序所使用的CPU百分比
Sys%:显示在内核模式下执行的程序所使用的CPU百分比
Wait%:显示等待IO所花的时间百分比
ldle%:显示CPU的空闲时间百分比
图表分析:随着并发数的升高,CPU出现等待的情况越多。

3、DISK_SUMM:显示所有磁盘的Read/Write的速率(KB/s)和所有磁盘的I/O速率
Disk Read kb/s :每个磁盘执行采样数据;(磁盘设备的读速率)
Disk Write kb/s :每个磁盘执行采样数据;(磁盘设备的写速率)
IO/sec: 每秒钟输出到物理磁盘的传输次数

4、NET:系统中每个网络适配器的数据传输速率(千字节/秒)
Total-Read,网络适配器每秒接收的数据包总大小,单位是KB/sec
Total-Write (-ve),网络适配器每秒发送的数据包总大小,单位是KB/sec

四、性能测试之数据库Mysql监控图表(天兔版)
(1)代表与MySQL已建立连接的线程数
分析:该数值一直处于100以上,150以下,其中正在运行线程比已连接线程的始终要低
打开my.cnf,修改max_connections=100(默认为100)。请根据硬件情况调整到合适的大小,一般经验值可设为3000。Windows服务器大概支持量为1500-1800个连接,linux服务器可以支持到8000个左右。
请将max_user_connections设0——–这个0代表不限制单用户的最大连接数,其最大连接值可以等于max_connections值。
mysql> show global status like ‘Max_used_connections’;
检查下最大的过往使用连接数,这个值在max_connections的85%左右是比较合适的,如果过高则是max_connections过少或者系统负荷过高了。

(2)QPS-TPS: 每秒查询数-每秒事物数,(服务器执行sql语句的数量)
分析:当100个并发用户数增加后,QPS明显升高较快,而TPS表现较为稳定。

(3)DML Persecond代表数据(查询、插入、更新和删除)
分析:当100并发提交后,select查询曲线明显升高,几分钟过后,select查询下降,直到17:15分,保持在100上线浮动,但insert、update保持在
30上下符动。这是因为我设置的性能测试场景有两个查询单场景,执行100次,所以刚开始查询量很大,而另外的综合场景是数据创建后执行查询。
delete并没有变现很强烈,尽管update稍微表现略有升高。【一般来说在编写SQL时,注意查询是否能使用到索引,是否在大表中或者高频率查询中引起
全表扫描,这些主要通过经验分析配合execution plan得到比较理想的查询消耗】

(4)Transaction Persecond:Com_commit:commit语句被执行的次数。Com_rollback:rollback语句被执行的次数。
分析:从图表可以得知,增大并发后,commit明显升高,但随着并发增大,commit并没有继续上涨。
rolleback一直处于0的值,说名MySQL数据库在增大并发后,并没有对数据库造成影响:rollback(回滚)

(5)Network:网络流量(吞吐量),Bytes_received:从所有客户端接收到的字节数。Bytes_sent:发送给所有客户端的字节数。
根据图表分析,服务器发送给客户端的一般保持在8000KB上下,换算为:8000KB/1024=8M左右,也就是每秒传输8M左右,其中当并发20和50和100时,Bytes_sent最大值都保持在8000KB上下。可以得知,局域网内传输成为了本次性能测试的瓶颈

(3)

本文由 小蜜蜂信息网 作者:admin 发表,转载请注明来源!

关键词:
LensNews

热评文章

发表评论