项目性能测试报告-练习版(无操作步骤，仅有结果)

无知之人_dream

于 2023-02-16 03:12:28 发布

阅读量178

点赞数

分类专栏： Java进阶之旅文章标签： java spring

本文链接：https://blog.csdn.net/qq_36630208/article/details/129052926

版权

Java进阶之旅专栏收录该内容

2 篇文章 0 订阅

订阅专栏

01-测试目的

练习Jmeter使用、学习性能分析、掌握压力测试基本能力、评估系统承受能力和分析系统瓶颈。

02-测试工具

共计4台 4C8G服务器，采用计量付费实例。
在这里插入图片描述

03-测试环境

3.1 环境

指标	参数
机器	4C8G
集群规模	单机
Application-Version	1.0
数据库	4C8G

3.2 设置启动参数

export JAVA_HOME
export JRE_HOME=${JAVA_HOME}/jre
export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib

export SERVER_NAME="application"
export JAVA="$JAVA_HOME/bin/java"
export BASE_DIR=`cd $(dirname $0)/.; pwd`
export DEFAULT_SEARCH_LOCATIONS="classpath:/,classpath:/config/,file:./,file:./config/"
export CUSTOM_SEARCH_LOCATIONS=${DEFAULT_SEARCH_LOCATIONS},file:${BASE_DIR}/conf/

JAVA_OPT="${JAVA_OPT} -server -Xms512m -Xmx512m -Xmn256 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
JAVA_OPT="${JAVA_OPT} -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${BASE_DIR}/logs/java_heapdump.hprof"
JAVA_OPT="${JAVA_OPT} -XX:-UseLargePages"
JAVA_OPT="${JAVA_OPT} -jar ${BASE_DIR}/${SERVER_NAME}*.jar"
JAVA_OPT="${JAVA_OPT} ${JAVA_OPT_EXT}"

JAVA_OPT="${JAVA_OPT} --spring.config.location=${CUSTOM_SEARCH_LOCATIONS}"
if [ ! -d "${BASE_DIR}/logs" ]; then
  mkdir ${BASE_DIR}/logs
fi
echo "$JAVA ${JAVA_OPT}"

if [ ! -f "${BASE_DIR}/logs/${SERVER_NAME}.out" ]; then
  touch "${BASE_DIR}/logs/${SERVER_NAME}.out"
fi

echo "$JAVA ${JAVA_OPT}" > ${BASE_DIR}/logs/${SERVER_NAME}.out 2>&1 &
nohup $JAVA ${JAVA_OPT} application.application>> ${BASE_DIR}/logs/${SERVER_NAME}.out 2>&1 &
echo "server is starting，you can check the ${BASE_DIR}/logs/${SERVER_NAME}.out"

04-测试场景

测试场景一般情况下是都是最重要接口：验证应用服务获取商品信息接口在不同并发规模的表现

情况01-模拟低延时场景，用户访问接口并发逐渐增加的过程。接口的响应时间为20ms，线程梯度：5、10、15、20、25、30、35、40个线程，5000次;

时间设置：Ramp-up period(inseconds)的值设为对应线程数
测试总时长：约等于20ms x 5000次 x 8 = 800s = 13分

情况02-模拟高延时场景，用户访问接口并发逐渐增加的过程。接口的响应时间为500ms，线程梯度：100、200、300、400、500、600、700、800个线程，200次;

时间设置：Ramp-up period(inseconds)的值设为对应线程数的1/10；
测试总时长：约等于500ms x 200次 x 8 = 800s = 13分

05-接口测试结果

情况01测试结果:
Jmeter测试结果报告,图1: 可以看到右侧线程数虽然在逐渐攀升,但是左侧的每秒通过没能稳定提高.
在这里插入图片描述
Jmeter测试结果,图2:可以看到随着线程增加,响应时间也逐渐增加,15-20 Thread的时候基本响应量达到顶峰,在35-40的时候甚至略有下降,99百分位的结果也接近于60ms。
Jmeter测试结果报告,图3: 响应结果可视化
主要查看应用服务器的状态:
CPU\内存\磁盘总体情况:
在这里插入图片描述
CPU使用率: 低延时场景下CPU占用率较高，但是尚未触顶，CPU可能产生了一定影响，但是应该不是瓶颈。

内存信息: 内存一直很低，不构成性能阻碍。

网络带宽情况: 服务器压测采用的是阿里云内网，理论上距离限制较远，但是该值接近于配置的公网峰值。（可以理解为，在公网情况下，超出此压力的请求将会受到公网带宽影响。
在这里插入图片描述
系统负载变化: CPU 1分钟负载抖动上升，基本高于5，5分钟负载缓慢爬升至4，15分钟负载缓慢至2，说明存在一定的CPU拥塞，但是尚未进入严重情况。

磁盘变化情况: 磁盘状态良好

网络IO情况: 网络状态较为稳定。
在这里插入图片描述
情况2测试结果:

Jmeter测试结果报告,图1: 可以看到右侧线程数虽然在逐渐攀升,但是左侧的每秒通过没能稳定提高.可以看到，在200线程以后，吞吐量就不再提高，可以推测是Tomcat设置的默认线程原因(时间问题没能进行800线程对比试验)，可以参考服务器状态进行验证。
在这里插入图片描述

Jmeter测试结果报告,图2: 数据可视化
在这里插入图片描述
应用服务器总览：
CPU、内存、硬盘检视：可以看到，除了硬盘意外，其他压力均低于低延时情况。

CPU使用率：远低于低延时情况，CPU利用率20左右，状态极为良好。

内存占用率：与低延时情况相差不大。
在这里插入图片描述
网络带宽：相比低延时情况下压力极低。

系统负载：负载稳定，长期维持1，1，1情况。

磁盘情况：

Socket信息：可以看到Socket随着压测方线程数增加而增加，所以可以断定链接是有效的，但是没能被正确的处理掉，导致了其他资源空转而处理缓慢的情况。
在这里插入图片描述