java 压力测试_记一次完整的java项目压力测试
经过本次压力测试实验后，在深入理解程序运行机制的基础上实现了关键业务功能；基于假设，在正常工作条件下该系统的方法执行时间约为2秒（即每秒处理次数达到100次），因此理论上最大支持约2千次/秒的并发请求；如果用户的响应时间期望不超过10秒，则理论上最多可支持约1千次/秒的并发请求；当系统吞吐量与并发处理能力接近极限时（即此时JVM的工作内存已接近上限），则需要转入Java开发人员熟悉的JVM性能调优阶段
基于测试结果不超过实际范围作为依据：压测参数在特定情况下作为依据设置。
1.接口最大响应时间(时间太长，客户要发彪)；
- 带宽大小（受限于运维部门的配置设置, 无法实现目标；建议及时与运维团队沟通以获取相关信息, 避免对其他业务的路由产生干扰）；
3.CPU(CPU爆顶，影响运维，和运维人员商定高峰CPU值)
4.JVM(JVM溢出还想啥啊，优化程序或者考虑加机器分流)
5.mysql最大连接数可达16384个（mysql默认最大可支持），安装完成后初始设置为100个连接，在实际使用中可能需要根据具体业务需求进行调整（考虑多业务共享同一数据库或集群部署的情况），建议按照专业团队的配置方案执行
6.待研究补充。
先记录这次的技术点：
JVM监控使用的是java自带jvisualvm.exe，在java安装目录jdk1.*/bin下;
使用教程：
- 服务器需要先配置jmx用户名和密码；基于Linux主机的环境。
- 将...文件复制至工程目录（以方便后续JVM参数配置）。
cp /apps/jdk1.8.0_112/jre/lib/management/jmxremote.password.template /apps/dt/
mv jmxremote.password.template jmxremote.password
vim jmxremote.password
配置jmxremote.password设置在最下方两个用户的属性以打开连接。
要在jmxremote.access中声明相应的权限才能访问。
chmod 0400 jmxremote.password
请配置项目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项目后,服务器已经正常完成了任务操作.打开JVisualVM.exe程序,按照提示依次完成以下步骤:首先添加远程主机信息,其次配置JMX监控功能,必要时请确保指定正确的端口号;同时,为了确保连接成功,用户名和密码必须与服务器上的JMX账户一致.
jmeter请访问apache jmeter官网获取软件包。下载完成后，请在本地创建jmx测试脚本（如有疑问，请自行查阅相关资料）。
流程：
将编写好的JMX文件传输至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
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"在数据库系统中，默认配置的连接池设置可能无法满足高负载测试的需求。如果压测程序依赖于频繁进行的数据操作，则需要特别关注单个应用程序的最大并发数作为影响测试效率的关键参数。由于不同应用程序通常共享同一个数据库资源，在某些情况下会发现当某个应用程序占用过多资源时（例如当某个应用程序占用过多的内存或CPU资源时），可能导致其他应用程序无法正常运行。因此，在实施压力测试之前，请务必与运维团队进行充分沟通，并根据具体情况进行合适的参数调整以确保系统的稳定性和响应能力。
``
``
#最大连接数据库连接数,设 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命令在本地环境运行测试，在另一台服务器上实现远程jvm状态监控功能。 条件 ：针对mysql数据库的操作场景设计如下：单库varchar类型的查询操作需要根据实际情况判断是否执行；对于插入操作，则要求每秒最多可以处理200次；在计算请求时长方面采用OCR接口进行处理：①从上传文件到我们的服务器返回的结果视为On时间；②文件从上传至第三方服务进行识别的过程也视为On时间，在对接环节对上述步骤进行阻塞处理，在测试结果中将两次On时间相加作为最终响应时间；确定有效请求的时间范围：假设业务方的一次图片识别操作在10秒内完成视为有效请求；只有在10秒内完成请求并在接口返回结果的情况下才算成功；对于非数据类型接口出现错误的情况必须严格处理，并明确此类错误属于运维层面的问题。
二、总结及建议
基于以下机器配置和运行条件，我们进行了多组测试并收集了以下数据：50组测试中分别取样了5×1e+2、1e+3、8×1e+2、7×1e+2和6×1e+2个样本点，在达到6×1e+2的并发数时系统性能达到最佳性能指标。测试结果表明未出现异常情况（Error），系统的处理能力稳定在2百至3百之间（即每秒处理约24十兆的数据），平均响应时间为2.一秒钟左右。此外，在持续5至十分钟的时间段内并未出现JVM相关异常问题。
随后部署了600并发的持续高负荷运行测试任务，在每日午夜结束前执行。未发现JVM异常问题，并确认所有日志记录一切正常。
基于上述分析，在没有封板的情况下（...）），系统的完整请求响应时间约为4.2秒左右（±），其吞吐量维持在100至150之间（单位：XXX），最高并发能力达到600。
测试附件
下图为：500并发到800并发的jvm情况
下图为聚合报告，顺序(按并发量)：500-600-700-800-1000
Label：每个JMeter的element的Name值。例如HTTP Request的Name
#Samples：发出请求数量。如第三行记录，模拟20个用户，循环100次，所以显示了2000
average: average response time (unit:). By default, it refers to the average response time for a single request. When transaction controllers are utilized, it is also possible to display the average response time in terms of transactions.
Median：中位数，也就是50%用户的响应时间
90%Line：90%用户的响应时间
95%Line：95%用户的响应时间
99%Line：99%用户的响应时间
注：考虑因素包括用户体验的一致性和系统的稳定性等多方面指标，在性能调优过程中单靠平均事务响应时间难以全面反映系统的实际情况。例如，在某个测试场景中,系统总共处理了100条请求,其中最小值为0.02秒,最大值达到110秒,而均值仅为4.7秒,这样的显著差异是否会影响我们对均值的信任?
我们可以随后继续添加这些数值，并利用Excel图表功能绘制一条曲线。这时你可能会注意到，在这些数值中最大的出现概率仅仅是千分之一甚至万分之一。而从另一角度来看，在性能需求定义范围内有超过百分之九十九的需求都能满足。例如，请参考下图所示的情况：最低响应时间出现的概率也很小。实际测试结果表明，在超过百分之九十九的情况下请求响应时间都会达到20,000+。
Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现错误的请求的数量/请求的总数
Throughput：吞吐量。默认情况下标示每秒完成的请求数(具体单位如下图)
KB/sec：每秒从服务器端接收到的数据量。
下图为响应时间，顺序(按并发量)：500-600-700-800-1000
下图为图形结果，顺序(按并发量)：500-600-700-800-1000
