- 压测端硬件、网络或软件
1.域名压测导致大量请求流向外网，并出现流量清洗
- 现象：测试结果显示tps非常低，请求量压测端统计与服务端统计相差很大
- 解题思路：确认压测域名是否走内网IP，ping+压测域名获取到的ip地址与运维确认是否为内网ip，若不支持ping，可尝试tracert。确定未走内容可能需要运维协助，在入口机器（nginx）配置host将域名指定到某台或多台服务器上。
2.Jmeter测试报告显示出现各种异常报错信息，如：500、502、non http responsecode
- 现象：控制台错误请求量增加、根据错误类型寻找错误提示、错误
- 解决思路：确定错误类型，根据错误类型寻找错误真实原因。（500：服务器内部错误，无法完成请求、502：充当网关或代理的服务器，从远端服务器接收到了一个无效的请求、400：客户端请求的语法错误，服务器无法理解、404：服务器无法根据客户端的请求找到资源（网页））其他状态详解见：blog.csdn.net/t_332741160…
3.Jmeter Jvm 分配内存不足导致内存溢出
- 现象：控制台出现报错，出现OutOfMemoryError
- 解决思路：Windows中对应的文件路径：Jmeter_Home/bin/jmeter.bat
- set HEAP=-Xms512m -Xmx512m
- set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
- Linux下对应文件路径：Jmeter_Home/bin/jmeter
- HEAP=-Xms512m -Xmx512m
- NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
- 通常就meter默认的HEAP -Xms512：初始化内存大小，-Xmx512m：最大堆内存。需要增 加内存的时候需要注意
- - 一般会将-Xms和-Xmx两个值配置为相同值，目的是为了能在java的GC完成后堆内存不需要重新分隔计算堆区大小而浪费资源
- - -Xms和-Xmx两个值修改的值一般需要为512的整数倍
- - -Xmx不要超过物理内存的50%，超出可能会导致jmeter变慢
- - 当脚本执行过程中出现内存溢出outfmenmory错误，先尝试增加增加HEAP的-Xms和-Xmx
- - JDK32位的电脑Xmx不能超过1500m，最大1378m.否则在启动Jmeter时会报错
- - -XX:MaxNewSize：新生代可被分配的内存的最大上限，这个值应该小于-Xmx的值，因为新生代占内存来自整个堆内存通常设置为-Xmx的三分之一
- - jvm在执行GC时，会停止工作。MaxnewSize的增大，可以降低GC频率
4.端口被占用
- 现象：并发6000次/s，错误率高达66.89%
- 错误日志：Non HTTP response code:java.net.BindException,Non HTTP response message: Address already in use
- 原因：Jmeter windows压测环境：Windows Server 缺失MaxUserPort和TcpTimedWaitDelay；限制了tcpip最大连接数和响应时间
- 解决办法：注册表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters;添加MaxUserPort和TcpTimedWaitDelay，分别设置值为65534、30，以增大可分配的tcp连接端口数、减小处于TIME_WAIT状态的连接的生存时间
2.服务器硬件、网络
1.压测方式使用的是域名压测，走的外部网络，所以压测压力未能如预期一样对目标服务器施压，导致TPS非常低，服务器各种资源消耗也很小。
- 现象：使用单台压测机器分别进行了100、500、1000进程压测，500个线程的时候tps只有180-200.再增加压力Tps上不去。
- 解决思路：一开始以为服务器连接数有问题，修改Tomcat最大连接数无效果。最后统计压测端请求量与被测服务器接收请求量相差比较大
- 解决方式：网络入口配置host/dns的形式将指定域名的请求全部指向测试服务器（对应IP）
2.原有集群到达最大限制，TPS达到280左右就出现CPU适应过高情况
- 现象：2台web和4台service在调整配置、代码优化出现瓶颈，使用单台压测机器分别进行了100、500、1000进程压测，500个线程的时候tps达到280位最高并发，90%响应时间最小而且CPU等资源正常，增加并发数到1000后tps降低、响应时间增加CPU使用率>70%
- 解决方法：增加集群机器
3. 中间件
1.Tomcat连接处瓶颈，导致高并发时出现接口超时
- 现象：500线程组并发的时候，服务端日志出现大量超时提示，排查Tomcat线程数配置的时候发现maxThreads(线程池中最大活跃线程数)为100
- 解决：修改maxThreads、accept-count为500后错误解决
- - maxThreads：最大请求进程数，默认设置为200，该值设置应该考虑实际情况，当
- 请求进程数达到最大值时，一般会出现错误提示：SEVERE: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status
- - accept：可接队列长度，与maxThreads对应，当达到maxThreads后进入等待队列。而等待队列数达到最大值后，再有新请求后就会出现refuse connection（拒绝请求）
2.502 Bad Gateway和504 Gateway Time-out
- 问题定位：tomcat的参数配置问题
- 解决办法：调整tomact配置文件server.xml的配置：主要是最大线程数、最大建立连接数和最长连接时间
3.JVM优化
- 现象：TPS每隔段时间就将为0
- 问题定位：（1）监控tcp的连接数，等待数；（netstat -an |grep 6222 | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'）（2）查看服务端FULL GC的次数（过多，FULL GC会导致所有线程
- 解决办法：JVM调优+ tomcat参数调优
- 1、取消飞行记录模式，去除参数（-XX:+UnlockCommercialFeatures -XX:+FlightRecorder）
- 2、jdk1.8 下取消了-XX:PermSize=500m-XX:MaxPermSize=500m
- 3、垃圾回收机制改成G1模式（堆内存被划分为固定大小的多个区域，存活的对象从一块区域转移到另一块区域，这样可以进行垃圾回收的同时不停止其他应用程序线程）
- JVM的常用参数如下：
- -Xms设置初始化堆的最大值
- -Xmx 设置堆的最大值
- PS：-Xms和-Xmx一般是相同的，可以减少Full GC的频率，最大可以到服务器总内存 的80%
- -Xmn 设置年轻代的大小（年老代=最大值-年轻代），一般为最大值的1/3左右。
4. 数据库、缓存等
1.DB优化
- 优化sql，尽可能少使用join、or语句，select出来的字段是必需的字段
- 优化索引，让每条select都走索引
- 设置连接池的最大连接数，设置为10000/14=700，(10000 为项目使用的mysql 最
大连接数,14 为机器数)
- 尝试测试不同的连接池，选择性能最佳的
- 不使用数据库事务，因为数据库操作代码都在消费者中，在代码中做幂等性。查询一条语句性能测试（ms）
2.redis优化存储数结构
- 将db 中的数据load 保存为redis 的hash 结构（全表保存），根据业务优化redis 存储结构，减少redis 查询次数(例如将phone 和券code 的领取状态单独存储)。
2.1.redis cpu为单核，进行分片处理
- 大量查询会成为严重短板，通过hash 值进行分片处理，因为项目不存在热点key 的问
题。优化过后redis 能够承受的量是之前的3 倍
2.2.设置redis最大连接数
- Redis 最大连接数设置为：3*10000/14 = 2100(这里乘以3 是因为微利项目有三台redis)
3.mq优化消息
- 消息体一般为redis key，可以去redis 拿取数据，优化消息存储大小。按功能不同，拆
分多个队列，加快单逻辑处理速度，微利项目根据业务拆分为5 个队列
3.1.加快消费者消费速度
- 增加消费者数量为20 个，根据下游(DB、业务方)TPS 多次测试得出，可以利用消费者数
量控制下游的负载。
- 增加消费者预读取数据数量为50 个，从而减少网络请求次数。
- 优化消费逻辑，完善幂等操作(解决消息重复消费问题)，db 操作，业务查询操作。
4.redis连接池pingjing
- 优化后配置：
redis.pool.maxTotal=5000
redis.pool.maxIdle=100
redis.pool.minIdle=50
- 关键参数说明：
maxTotal：资源池中最大连接池，默认值8
- 最大连接数的配置需要结合实际情况进行调整，而考虑的关键因素包括：
- 业务要求Redis达到的并发量
- 客户端执行命令时间
- Redis资源：如应用个数*maxTotal不能超过Redis的最大连接数
- 资源开销：控制空闲连接，尽量使连接池的频繁创建、释放造成不必要的开销
- 参考资源详见：yq.aliyun.com/articles/23…
