java工程压力测试_记一次完整的java项目压力测试

java⼯程压⼒测试_记⼀次完整的java项⽬压⼒测试

总结：通过这次压⼒测试，增加了对程序的理解；假定正常情况下⽅法执⾏时间为2秒，吞吐量为100/s，则并发为200/s；假设⽤户可接受范围为10s，那么并发量可以继续增加到1000/s，到这个时候⼀切还都正常，若想继续提⾼并发量，我们可以优化吞吐量，增加tomcat的线程数和mysql的连接数；当吞吐量和并发量都达到⼀定程度，我们的JVM已经爆仓，则到了java开发最喜欢的JVM调优环节。

本着压测结果不能超脱实际情况裸奔的前提，压测参数在特定情况下参照：

1.接⼝最⼤响应时间(时间太长，客户要发彪)；

2.带宽⼤⼩(线上机器带宽被运维限制，你想飞，飞不起来；内部带宽⼤⼩最好通知运维⼈员，防⽌影响路由其他业务)；

3.CPU(CPU爆顶，影响运维，和运维⼈员商定⾼峰CPU值)

4.JVM(JVM溢出还想啥啊，优化程序或者考虑加机器分流)

6.待研究补充。

先记录这次的技术点：

JVM监控使⽤的是java⾃带，在java安装⽬录jdk1.*/bin下;

使⽤教程：

1.服务器先要添加jmx⽤户名和密码，我的主机为linux，把jdk*/jre/lib/management/plate⽂件拷贝到⼯程⽬录中(⽅便jvm参数配置)；

cp /apps/jdk1.8.0_112/jre/lib/management/plate /apps/dt/

mv plate jmxremote.password

vim jmxremote.password

2.编辑jmxremote.password最下⾯两个⽤户#打开，如果想增加⽤户或者修改⽤户名需要在jmxremote.access声明权限才可以访问到。

chmod 0400 jmxremote.password

3.编辑项⽬的sh启动⽂件或者tomcat的catalina.sh，JAVA_OPTS中添加如下参数(注意参数之间的空格分开)

-Xms2g -Xmx2g -XX:PermSize=64m //jvm内存参数，请百度。

-server

-Dcom.sun.management.jmxremote.ssl=false //是否使⽤ssl

-Dcom.sun.management.jmxremote.port=10090 //jmx监控端⼝

-Dcom.sun.management.jmxremote.password.file=jmxremote.password //远程监控⽤户和密码⽂件

4.启动java项⽬，服务器⼯作就已经完成了。在本地打开，添加远程主机，添加JMX监控，端⼝必填，⽤户名和⼝令需要和服务器上的jmx⽤户⼀致。

jmeter请到apache jmeter官⽹下载，下载完成，本地编写jmx测试脚本(如何编写请⾃⾏百度)

流程：

1.将编写好的jmx发送到linux服务器，linux下载jmeter包或者上传本地的jmeter。

2.配置jmeter命令，⽅便执⾏脚本；

vim /etc/profile

export JMETER_HOME=/dt/apache-jmeter-3.1

export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$CLASSPATH

export PATH=$JMETER_HOME/bin:$PATH

source /etc/profile

jmeter -v

3.执⾏jmx脚本，并记录测试⽇志jtl⽂件。

jmeter -n -t 测试.jmx -l log.jtl

4.把log.jtl拿到本地在jmeter中各种报告导⼊查看。

⼀、测试⽬的、准备及条件

测试⽬的：得到我们的程序最优最⼤并发量，机器吞吐量(处理速度)，带宽、计算⼒、JVM内存等情况，⽅便后续程序调优，⽅便后续给出运维建议。

准备及条件

测试机配置：

操作系统

CentOS release 6.8

数控机床防护罩

CPU

Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz

内存

带宽

本机部署，本机测试，带宽忽略

192.168.1.149:11090

路由

水性阻燃剂包含上百台办公设备的路由

JVM参数配置：

MEM_OPTS="-Xms2g -Xmx2g -XX:PermSize=64m -server -Dcom.sun.management.jmxremote.ssl=false -

Dcom.sun.management.jmxremote.port=10090 -Dcom.sun.management.jmxremote.password.file=jmxremote.password"

数据库连接池：如果压测程序依赖数据库数据操作，那么数据库最⼤连接数是影响压测性能的⼀个重要因素，连接池在单个程序中并不是越⼤越好，因为所有程序共享⼀个数据库，某个程序连接数沾满，会造成其他程序⽆法访问数据库。所以这⾥需要跟运维⼈员沟通后，在确认连接数的⼤⼩设置。

#最⼤连接数据库连接数，设 0 为没有限制

spring.datasource.max-active=20

#最⼤等待连接中的数量，设 0 为没有限制

spring.datasource.min-idle=8

#连接初始数量

spring.datasource.initial-size=10

tomcat线程池：假设⼀个并发数占⽤⼀个线程(BIO⽅式，实际情况使⽤NIO或APR⽅式，并发数可以⽐线程数⼤很多)，⾼并发在数据库和CPU和JVM内存中任意⼀个为爆满情况下，增⼤tomcat线程数，可以提⾼单个服务并发数。

port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

minProcessors="20"

监视器安装

maxProcessors="300"

acceptCount="1000"/>

executor：表⽰使⽤该参数值对应的线程池；

minProcessors：服务器启动时创建的处理请求的线程数；

maxProcessors：最⼤可以创建的处理请求的线程数；

脱标机acceptCount：指定当所有可以使⽤的处理请求的线程数都被使⽤时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。

⼯具：使⽤jmeter命令在本机测试，VisualVM远程jvm状态监控。

条件：mysql数据库：单库varchar查询，插⼊需要判断实际情况，如果查询与插⼊每次都需要执⾏，则每秒中最多执⾏200次，请求时间计算：选⽤OCR接⼝，①将上传⽂件到我们服务器的响应时间看做On，②⽂件上传⾄提供商服务器进⾏识别的时间看做On，我们对接⼝中②步骤做挡板，测试结果中响应时间*2作为最终响应时间；有效请求的时间划定：假定业务⽅⼀次图⽚识别得到结果的最⼤可接受时间为10s，则⼀旦超过10s则认为此结果为⽆效数据；有效结果认定：需满⾜在10s内完成请求

且能拿到接⼝结果才可算是成功的请求；业务产品要求：⾮数据问题的接⼝报错绝对不可接受，此情况为运维机器层⾯的问题，压⼒结果需到此为⽌；

⼆、总结及建议

以如上机器配置和条件，我们分别抽样了500/1000/800/700/600，最终600并发量为最优，结果⽆Error产⽣，机器吞吐量维持在200-300之间，每秒发送数据240M，响应时间平均为2.1s左右，jvm运⾏正常，5-10分钟时间运⾏并没有出现jvm异常的情况。

后续我们选择600并发进⾏16⼩时⾼并发测试，早晨8点到晚上12点，jvm⽆异常出现，⽇志正常。

女性快乐器

综合以上结论，理论上⽆挡板的完整请求响应时间为4.2s左右，吞吐量在100-150之间，并发最优为600。

测试附件

下图为：500并发到800并发的jvm情况

引向器

下图为聚合报告，顺序(按并发量)：500-600-700-800-1000

#Samples：发出请求数量。如第三⾏记录，模拟20个⽤户，循环100次，所以显⽰了2000

Average：平均响应时间(单位：)。默认是单个Request的平均响应时间，当使⽤了Transaction Controller时，也可以以Transaction为单位显⽰平均响应时间

Median：中位数，也就是50%⽤户的响应时间

90%Line：90%⽤户的响应时间

95%Line：95%⽤户的响应时间

99%Line：99%⽤户的响应时间

注：为什么要有*%⽤户响应时间？因为在评估⼀次测试的结果时，仅仅有平均事物响应时间是不够的。假如有⼀次测试，总共有100个请求被响应，其中最⼩响应时间为0.02秒，最⼤响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最⼩和最⼤响应时间如此⼤的

偏差是否会导致平均值本⾝并不可信？

我们可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利⽤Excel的图表功能画⼀条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最⼤值的出现⼏率只不过是千分之⼀甚⾄万分之⼀，⽽且99％的⽤户请求的响应时间都是在性能需求所定义的范围之内的；如下图则是最低响应时间的值出现⼏率是很⼩的，实际99%的⽤户请求响应时间都要20000+。

Min：最⼩响应时间

Max：最⼤响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数

Throughput：吞吐量。默认情况下标⽰每秒完成的请求数(具体单位如下图)

KB/sec：每秒从服务器端接收到的数据量。

下图为响应时间，顺序(按并发量)：500-600-700-800-1000

本文发布于:2024-09-22 23:28:04，感谢您对本站的认可！

本文链接：https://www.17tex.com/tex/1/224937.html

上一篇：性能压力测试指导方案

下一篇：jmeter-压力测试的结果报告分析