一次压测性能优化

优化点如下：

1、后端服务原来提供restful接口进行调用，会将一些请求参数放在url中，后端通过@PathVariable进行获取，但是采用这种方式在springmvc中定位具体handler时会进行遍历、模糊匹配，影响性能。后均优化为非restful方式，参数统一放在url的？符号后，或直接放在requestBody中，处理性能提高20%以上。

相关参考：https://tech.imdada.cn/2015/12/23/springmvc-restful-optimize/

2、原规则决策流会从内存数据库中获取数据，采取方式是当决策流走到需要获取数据的地方即从内存数据库同步获取。一个决策流需获取多次，造成多次同步等待。因为绝大部分交易都是正常都需走满整个决策流，因此将获取数据采用异步方式，开始便发送多个get请求，采用listenablefuture+completeablefuture纯异步化，当走到需要内存数据当时候直接future.get，这样多次同步等待时间变成了最长一次同步等待时间，甚至在这段等待时间都可以继续走其他流程，提高并发

3、socket转http的解析服务中，获取json后需要解析parse成map,压测时用jprofiler观测fastjson的parse方法消耗大量cpu时间，后修改为jackson解析方式，cpu有所下降

4、观测应用gc发现绝大部分创建的对象都是朝生夕死的，gc主要发生在年轻代，而刚开始年轻代太小导致youngGC频繁，cpu飙高。于是将jvm内存调大，将年轻代调大-Xms4G -Xmx4G -XX:PermSize=500M -XX:MaxNewSize=2G。调整后tps1400左右时年轻代GC变为3～4秒一次，基本没有fullGC。gc导致的cpu飙高得以缓解

5、netty服务的线程池模型采用work+boss，且业务handler采用单独的eventloopgroup线程池进行处理，防止堵塞io线程，提高吞吐量。线程数量采用  线程数 = CPU核心数/(1-阻塞系数) 确定，一般为cpu核数5～10倍

6、netty服务运用了PooledByteBufAllocator.DEFAULT进行堆外内存分配，以减少堆内内存分配的GC压力，结果在压测到180W笔的时候报错：OutOfDirectMemoryError。分析发生了堆外内存泄漏，查看代码发现在业务handler代码中，将bytebuf转换成string处理时，用了    String message = msg.readBytes(msg.capacity()).toString(Charset.forName(charset));   这个方法会将原来的bytebuf复制一份在堆外，然后再返回一个string对象，但是复制的这份bytebuf没有手动release，导致每次请求都泄漏了这么一份数据内存，后直接用bytebuf.toString()方法即解决此问题

7、在用jmeter压测时候，发现jmeter时不时报错：java.net.BindException: 无法指定被请求的地址，分析后端并没有收到此请求，应该是jmeter自己报错了，后使用 netstat -apn|grep pid 查看发现jmeter应用有大量timewait状态。原因是服务采用短链接，在tcp四次挥手后，会有一段时间的timewait状态，默认120s，这段状态时间内，socket的fd句柄不会释放，但是linux单进程最大打开句柄数配置的是65536，在极高并发下，120s时间内会将句柄用完，导致无法建立新的socket连接。因此在sysctl.conf新增配置：

#开启TCP连接中time_wait sockets的快速回收
net.ipv4.tcp_tw_recycle = 1  
#开启TCP连接复用功能，允许将time_wait sockets重新用于新的TCP连接（主要针对time_wait连接）
net.ipv4.tcp_tw_reuse = 1  

问题解决

8、Strace观测进程中cpu占用最高的进程都在干啥，发现大量的cpu时间耗费在了epoll_wait状态，分析由于服务端访问内存数据库采用了netty client访问，高并发下确实会不断检测epoll句柄是否就绪。但是此内存数据库的client端采用的netty线程模型为单线程组模型，且线程数为cpu核数，则这些线程不但负责连接创建，也负责数据收取处理，未做reactor容易跑满cpu，因此优化了此线程模型为work-boss，cpu略有下降