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
内存
4G
带宽
本机部署，本机测试，带宽忽略
IP
java安装完整教程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
数据库连接池： 如果压测程序依赖数据库数据操作，那么数据库最⼤连接数是影响压测性能的⼀个重要因素，连接池在单个程序中并不是
越⼤越好，因为所有程序共享⼀个数据库，某个程序连接数沾满，会造成其他程序⽆法访问数据库。所以这⾥需要跟运维⼈员沟通后，在确
认连接数的⼤⼩设置。
#最⼤连接数据库连接数，设 0 为没有限制
spring.datasource.max-active=20
#最⼤等待连接中的数量，设 0 为没有限制
spring.datasource.min-idle=8
#连接初始数量
spring.datasource.initial-size=10
tomcat线程池： 假设⼀个并发数占⽤⼀个线程(BIO⽅式，实际情况使⽤NIO或APR⽅式，并发数可以⽐线程数⼤很多)，⾼并发在数据库和
CPU和JVM内存中任意⼀个为爆满情况下，增⼤tomcat线程数，可以提⾼单个服务并发数。
<Connector executor="tomcatThreadPool"
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
Label：每个JMeter的element的Name值。例如HTTP Request的Name
#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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。