并发瓶颈:当请求从每秒2.7万递增到3万的过程中,我们的TPS由6000下降到了4500,可以看到并发瓶颈就在每秒最多处理6000请求
响应时间:我们可以看到TPS保持在3500或之下,99%用户用户的响应时间为11毫秒,随着TPS的升高,我们的响应时间也在随着升高,可以看到我们的TPS在每秒3500响应的时候,对响应时间是没有影响的。
注意:这个只是我的业务其中的一个接口,我们生产有上百个接口,不同的接口返回数据还有代码逻辑,以及执行的sql均不相同,如果需要做性能测试,应该选择其中的热点接口,对每个接口进行性能测试,得到结果之后在进行具体的分析性能瓶颈到低是什么?
聚合报告参数说明:单位为毫秒
Label:定义HTTP请求名称
Samples:表示这次测试中发出了多少个请求
Average:平均响应时长——默认情况下是单个request的平均响应时长
Median:中位数,也就是50%用户的响应时长
90% Line:90%用户的响应时长
Min:访问页面的最小响应时长
Max:访问页面的最大响应时长
Error%:错误请求的数量/请求的总数
Throughput:默认情况下表示每秒完成的请求数(request per second)
KB/Sec:每秒从服务器端接收到的数据量
6、测试中的监控
1)并发测试监控
并发测试直接发起指定数量的请求,比如一起发起10万请求看一下系统的处理能力,这个时候如果需要服务器的资源使用信息,就不能使用比如zabbix监控系统了,因为一般处理10万请求,对于我们来说20秒可以处理完毕,但是zabbix数据采集是每分钟一次,这样采集到的数据明显是不准的,这样就需要通过系统自带的监控命令,来实时查询服务器的性能,比如可以通过dstat或者glances等动态监控命令来分析系统的性能。
补充:不是测试每一个接口都需要进行这样的实时监控,比如过测试我的大部分接口TPS可达5000,但是其中一个接口只能达到2000这个时候就需要在测试的时候实时监控,看一下到底是什么原因导致性能上不去。是由于返回数据太大导致网络带宽被占满;还是sql执行时间太长导致数据库负载高,还是代码有问题导致web服务cpu占用高。
2)稳定性测试监控
稳定性测试就是持续不断模拟指定数量请求,来访问服务器,比如我每秒向测试服务器发起4000请求,持续12小时,来看看服务器会出现什么情况,这个时候就需要用到zabbix来进行监控了,下面是我做性能测试的部分监控接口,包含tomcat每秒请求,服务器入口流量,整个集群每分钟请求的http状态码统计,还有服务器资源使用信息。
本文源自 西门飞冰 博客: http://www.fblinux.com/?p=951