性能测试

合同XXX接口压力测试报告

LensNews

1、测试概述
1.1、目的
针对合同XXX接口进行压力测试,客观公正的评估API在服务器上的性能状况。
1. 正确有效的【开发压力测试脚本,脚本包括:用户登陆、用户信息保存、学历信息保存、工作经历保存、家庭情况保存以及合同创建和签署等接口测试脚本
2.通过本次压力测试,评估在当前服务器测试环境下被测接口的各项性能表现;
3.验证被测系统的事务处理能力是否满足在高峰时期的性能要求,为被测系统提供参考依据。为性能瓶颈进行分析提供参考依据

1.2、测试方法
压力测试采用Jmeter性能测试工具、通过创建压力测试程序,对被测服务器与接口进行自动化压力测试,最后形成压力分析报告

1.3、测试结论
在50个用户并发情况下【无集合点】,应用服务器以及MySQL服务器均表现正常,这说明,我们的MySQL以及应用服务器硬件配置还是比较好的,并且50个并发也不大。

2、测试结果概述
2.1、测试结果分析

2.2、客户端测试结果记录【50个用户并发】
场景一:晚上20:01分,50个并发,执行10分钟,添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为50时,XXX后台签署【/contract/sign/pageSignNew】以及XXX页面签署【/contract/sign/pageSignNew】
均出现错误,这样可以通过查看后台日志分析错误原因,定位错误原因并加以优化。
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到960毫秒,差不多就是1秒了,其中页面签署接口最大响应时间为9秒
3. Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。平均每分钟处理37个请求,总体上服务器每秒处理5.1个请求

场景二:晚上20:16分,50个并发,执行10分钟,没有添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为50时,XXX后台签署【/contract/sign/pageSignNew】以及XXX页面签署【/contract/sign/pageSignNew】
均出现错误,这样可以通过查看后台日志分析错误原因,定位错误原因并加以优化。
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到960毫秒,差不多就是1秒了
3. Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。平均每分钟处理37个请求,总体上服务器每秒处理5.1个请求

场景一与场景二两次压力测试结果综合分析:
50个并发情况下:图表【事务数/秒,展示服务器每秒处理的事务数随时间变化情况】,场景一与场景二每秒事物处理对比图:右边曲线部分表示【已添加集合点】,左边曲线部分表示【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但左边曲线的高度明显高于右边曲线,原因在于是否添加了集合点,如果添加了集合点,就相当于所有的并发请求,都会在同一个时刻进行请求
2.从faulure来看,silentSign以及pageSignNew均出现错误,其他的接口都success
3.每秒事务数可以根据聚合报告比较直观的看出,左边曲线的每秒事务数整体上在20左右,右边曲线整体上在10个左右

50个并发情况下:图表【随着时间推移响应时间变化趋势图】,场景一与场景二响应时间对比图:右边曲线部分【已添加集合点】,左边部分【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但右边曲线的整体上高度明显要高于左边曲线。
2.响应时间整体上比较快,大部分都在2000ms以内,换算为2秒,不过最大值有超过9000ms,主要是pageSignNew以及SaveContractInformation两个接口

2.3、测试结果记录【100个用户并发】
场景一:晚上20:47分,100个并发,执行10分钟,已添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为100时,XXX后台签署【/contract/sign/pageSignNew】以及XXX页面签署【/contract/sign/pageSignNew】
还有用户登陆以及创建合同均出现不同概率的错误,这样可以通过查看后台日志分析错误原因,定位错误原因并加以优化。
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到1316毫秒,比50个用户略高,其中,创建合同最大响应时间超过21秒
3. Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。平均每秒钟处理1.1个请求,总体上服务器每秒处理9个请求,高于50个并发时的5个请求
4. 每秒接收和发送的字节数为:10.3KB/sec 和 11.56KB/sec

场景二:晚上21:02分,100个并发,执行10分钟,没有添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为1000时,当没有添加集合点,错误率有所下降,但不用于50个并发时的没有错误的情况。说明达到100个并发时,应用接口会出现一定的问题的风险还是比较大的,建议通过错误日志进行处理优化。
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到1198毫秒,差不多就是1秒以上了,最大的响应时间为21秒,这时间有点长,说明当并发数比较大的时候,后台处理有点阻塞的可能
3. Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。平均每分钟处理57个请求,总体上服务器每秒处理8.3个请求
4. 每秒收到和发送的字节数为:9.21KB/sec 和 10.74KB/sec

场景一与场景二两次压力测试结果综合分析:
100个并发情况下:图表【事务数/秒,展示服务器每秒处理的事务数随时间变化情况】,场景一与场景二每秒事物处理对比图:右边曲线部分表示【已添加集合点】,左边曲线部分表示【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但左边曲线的高度明显高于右边曲线,原因添加了集合点会花等待所有线程在同一时刻,所以左边密度会少很多,等待的过程时没有请求的;高度要
高的话,那就表明在一个时间点上,请求的用户数是高于没有集合点的
2.从faulure来看,silentSign以及pageSignNew以及login还有createContract均出现错误,其他的接口都success,也高于50个并发的错误的接口数量
3.每秒事务数可以根据聚合报告比较直观的看出,左边曲线的每秒事务数整体上是在40个左右,右边曲线整体上在20个左右

50个并发情况下:图表【随着时间推移响应时间变化趋势图】,场景一与场景二响应时间对比图:右边曲线部分【已添加集合点】,左边部分【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但右边曲线的整体上高度明显要高于左边曲线。
2.响应时间整体上比较快,大部分都在2000ms以内,换算为2秒,不过最大值有超过9000ms,主要是pageSignNew以及SaveContractInformation两个接口

2.4、测试结果记录【200个用户并发】
场景一:晚上21:34分,200个并发,执行10分钟,已添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为200时,错误比较明显的是:XXX后台签署【/contract/sign/pageSignNew】以及XXX页面签署【/contract/sign/pageSignNew】
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到7094毫秒,比100个用户高7倍,其中,创建合同最大响应时间超过23秒
3. Throughput吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。平均每秒钟处理1.6个请求,总体上服务器每秒处理10.8个请求,高于50个并发时的1.8个请求,感觉并发数增加了一倍,这个吞吐量增加了有点少,这说明,服务器处理请求的效率没那么好了。而且Samples一栏中,总计处理7000个请求,略高于100个并发的5500个,而不是预计的10000个。
4. 每秒接收和发送的字节数为:12.51KB/sec 和 14.08KB/sec

场景二:晚上21:48分,200个并发,执行10分钟,没有添加【集合点】,聚合报告
1. Error%指测试出现的错误请求数量百分比,可以看出当并发数为200时,当没有添加集合点,错误率有所下降,但是错误还是会有,相对没有添加了集合点那么大的错误率
2. Average平均响应时间可以看出不同接口的响应时间区别较大,其中XXX创建合同接口的响应时间最高,达到2954毫秒,差不多就是3秒,最大的响应时间为23秒
3. Throughput吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力。单个接口平均每秒钟处理1.7个请求,总体上服务器处理所有请求是每秒处理14.4个请求,比添加了几个点要高,说明添加集合点的话,所有的请求一起压过去,服务器有点吃不消,会损耗服务器的处理速率。
4. 每秒收到和发送的字节数为:15.95KB/sec 和 18.71KB/sec

场景一与场景二两次压力测试结果综合分析:
200个并发情况下:图表【事务数/秒,展示服务器每秒处理的事务数随时间变化情况】,场景一与场景二每秒事物处理对比图:右边曲线部分表示【已添加集合点】,左边曲线部分表示【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但左边曲线的高度明显高于右边曲线,原因添加了集合点会花等待所有线程在同一时刻,所以左边密度会少很多,等待的过程时没有请求的;高度要
高的话,那就表明在一个时间点上,请求的用户数是高于没有集合点的
2.从faulure来看,silentSign以及pageSignNew以及login还有createContract均出现错误,其他的接口都success,也高于50个并发的错误的接口数量
3.每秒事务数可以根据聚合报告比较直观的看出,左边曲线的每秒事务数整体上是在40个左右,右边曲线整体上在20个左右

50个并发情况下:图表【随着时间推移响应时间变化趋势图】,场景一与场景二响应时间对比图:右边曲线部分【已添加集合点】,左边部分【没有添加集合点】
1.从两边的曲线图可以看出,右边曲线密度明显高于左边曲线,但右边曲线的整体上高度明显要高于左边曲线。
2.响应时间整体上较好,大部分都在3000ms以内,不过最大值有超过21000ms,主要是pageSignNew以及createContrat两个接口

3、服务器端测试记录
3.1、MySQL服务器性能监控
1. QPS-TPS: 每秒查询数-每秒事物数,(服务器执行sql语句的数量)分析:当并发用户数增加后,QPS明显升高较快,而TPS表现较为稳定。但当并发为20个和50个或100个时,QPS表现最高都在4000点附近,因此可推断,当并发数升高后,4000点是QPS是数据库可最大处理的每秒查询数

2. DML Persecond代表数据的查询、插入、更新和删除,从图表可以知道,当并发升高后,select查询曲线明显升高,但当并发继续增加后,select并没有继续提升,而是继续保持在2000点附近的值,但insert、update、delete并没有变现很强烈,尽管update稍微表现略有升高。

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

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

3.2、应用服务器
下图是最大并发数【200个并发】情况下,监控到的173应用服务器资源利用率的曲线图,整体情况可以看下面的表格数据:从表格中可以看到CPU资源利用率并不高,说明应用服务器硬件配置完全满足200个并发情况

(2)

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

关键词:,
LensNews

热评文章

发表评论