接口压测性能分析及调优手段建议

╰+哭是因爲堅強的太久メ 2021-09-15 06:16 302阅读 0赞

常见的互联网架构中，一般都能看到spring+mybatis+mysql+redis搭配的身影，在我所服务的公司亦是如此。一般来说，应用内部的接口都是直接调用的，所谓的面向接口编程，应用间的调用直接调或者通过类似dubbo之类的服务框架来执行，数据格式往往采用json，即统一也方便各数据间做转换和取值，缓存一般使用redis或memcached，存储一些对象或json格式的字符串。对外提供的接口，一般都需要进行压力测试，以便估算其性能，并为后续的调优提供指导方向，以下接口便是在压测过程中出现的各种“奇怪现象”，所谓奇怪，指的是从表象上看与我们正常的逻辑思路不符，但其本质还是我们对压力下程序的表现出来的特征不熟悉，用惯用的知识结构试图去解释，这根本是行不通的。下文是我在一次全面压测过程后对数据进行的分析汇总，其中的现象是很多压测常见的，里面的分析过程及改进措施我认为有很大的参考意义。具体内容如下：（部分接口为了安全我省略了其名称，但不影响我们的分析，另外形如1N3T之类的表示的是1台nginx，3台tomcat,具体的tps数值只是为了说明优化前后的比照，没有实际意义）

## 1        接口名称: 获取列表 ##

## 1.1      压测现象:单台tps700多，应用cpu高负载 ##

### 1.1.1        问题分析: ###

旧框架，平均响应时间长，应用CPU高，程序内部有大量的bean到map到json之间的转换，修改数据库连接数后，tps没有提升。

### 1.1.2        改进措施: ###

重构系统，用mybatis替代之前的dao操作，减少bean-map-json之间的内部数据转换，减少程序内部的无用操作。

### 1.1.3        改进效果: ###

tps改进后能到3000左右，有较大提升，但压测时应用cpu几乎跑满，还有改善空间。

## 1.2      压测现象：数据库资源利用率高 ##

### 1.2.1        问题分析: ###

单台应用，数据库资源cpu都能到50%，10台tomcat在1万并发下数据库cpu跑满，load值700多，但db的qps也不过11554，并不算多，因此怀疑是sql执行耗费了cpu，可能是某条sql没有按索引查找或者索引失效。

### 1.2.2        改进措施: ###

查看SQL文件发现如下sql：select count(1)  from orders where order\_status\_id !=40 ，将其改为select order\_id from orders  然后通过程序把order\_status\_id!=40的过滤掉。通过list.size()来获取。order\_status\_id即使加了索引，由于是！=比较，所以不会去按索引查找，导致cpu高

### 1.2.3        改进效果: ###

相同环境下(1台nginx，10台tomcat，1000并发)，tps由3000变成3727，略有增长，但是db的cpu明显下降，变为30%，效果明显

## 1.3      压测现象:1N15T ,tps4552;10N15T,tps9608 ##

### 1.3.1        问题分析: ###

后端都是15台tomcat，前端1台nginx时tps为4552,通过lvs挂10台nginx时为9608，增长不明显，其nginx和tomcat都压力不大，集群结果不合理，怀疑是nginx转发配置的问题；

### 1.3.2        改进措施: ###

未进一步改进：可能是需要调整nginx的参数，之前发现过nginx不同的配置对后端集群环境的tps影响很大

### 1.3.3        改进效果: ###

## 2        接口名称: 信息查询接口 ##

## 2.1      压测现象:单台tps2000多，应用cpu高，db的qps15000左右 ##

### 2.1.1        问题分析: ###

旧框架，程序内部有很多Bo-map-json相互的转换

### 2.1.2        改进措施: ###

删除冗余代码、更换连接池包，使用mybatis

### 2.1.3        改进效果: ###

Tps由2000多增长为8000多，db的qps为9000左右，优化后压测应用的cpu占用高，几乎跑满。

## 2.2      压测现象：数据库无压力，应用增加多台后tps不变 ##

### 2.2.1        问题分析: ###

1N1T和1N10T的tps一样，都为5000，增大并发时错误数增多，应用cpu耗费70%，db无压力，nginx单台通过ss –s 发现端口占满，即nginx到tomcat之间转发的连接端口time-wait状态6万多。Nginx存在瓶颈。

### 2.2.2        改进措施: ###

调优nginx参数，将短连接改为长连接

### 2.2.3        改进效果: ###

1N3T的tps能到17376，tomat的cpu压力84%，db的qps18000，cpu69%，应用的资源基本使用到量。

## 3        接口名称: 获取详情 ##

## 3.1      压测现象:单台应用tps2600，10台tomcat才3700 ##

### 3.1.1        问题分析: ###

增加应用服务器，tps增长不明显，且nginx、tomcat、db的负载都不高，说明服务器本身不是瓶颈，考虑是不是网络的问题，通过监控网卡包流量发现网络数据跑满，因为此接口会有大量数据的输出，因此瓶颈在网络上。另外，测试过程中发现redis有报错，redis服务器是虚机，可能服务能力有限。

### 3.1.2        改进措施: ###

开启tomcat的gzip压缩。

### 3.1.3        改进效果: ###

同等并发下(1台nginx，10台tomcat，1000并发)，tps由3727增长到10022，增长了近3倍，效果显著。

## 3.2      压测现象:1N10T集群下nginx参数调优对tps提升效果明显 ##

### 3.2.1        问题分析: ###

经过tomcat的启用gzip后，1N10T下tps为10022，需进一步提升。

### 3.2.2        改进措施: ###

优化nginx：

l  nginx日志关闭

l  nginx进程数量worker，由24改为16

l  nginx  keepalive数量由256改为2048

### 3.2.3        改进效果: ###

Tps由10022提升为13270。

## 3.1      压测现象:1N5T和1N10T的tps相差不大 ##

### 3.1.1        问题分析: ###

1N10T的tps为1万3千多，1N5T的tps为1万2千多，相差不大，应用的tomcat资源利用没满，cpu为65%，Db的QPS已经到2万多了，单台服务器db基本上到量了，因此再增加应用也没效果，只会导致响应的时间变长。

### 3.1.2        改进措施: ###

单台db已经无法改进了，要不提升服务器硬件，要不读写分离。

### 3.1.3        改进效果: ###

## 4        接口名称: 促销 ##

## 4.1      压测现象:通过redis存取数据，tps才1000多，CPU 有压力 ##

### 4.1.1        问题分析: ###

此接口通过redis取数据，tps不高才1000多，但cpu占用了80%，说明程序内部有大量序列化反序列化的操作，可能是json序列化的问题。

### 4.1.2        改进措施: ###

将net.sf.json改成alibaba的fastjson。

### 4.1.3        改进效果: ###

同等并发条件下tps由1000多提升为5000多，提高了近5倍。

## 4.1      压测现象:参数多时tps下降明显 ##

### 4.1.1        问题分析: ###

此接口根据参数从redis中获取数据，每个参数与redis交互一次，当一组参数时tps5133，五组参数时tps1169，多次交互影响了处理性能。

### 4.1.2        改进措施: ###

将从redis获取数据的get改为mget，减少交互次数。

### 4.1.3        改进效果: ###

五组参数时1N3T压测TPS9707，据此估算即使是单台tomcat，tps也能有三四千，性能比单次get的调用方式提升了3,4倍。

## 4.2      压测现象:1N3T tps1万多，在增大tomcat可能tps增长不会明显 ##

### 4.2.1        问题分析: ###

此处说的是可能，因为nginx服务器的cpu虽然不高，但pps已经800多k，此时应该是nginx的服务器网络流量成为了瓶颈。(只是猜测)

### 4.2.2        改进措施: ###

可以增加多台nginx负载，前端加lvs

### 4.2.3        改进效果: ###

## 5        接口名称: 追踪接口 ##

## 5.1      压测现象:1N10T的tps低于1N3T的tps ##

### 5.1.1        问题分析: ###

1N3T在2000并发下tps为9849，此时db的qps为90000，CPU80%，将tomcat增到10台，5000并发下,tps为7813，db的qps为19000，cpu75%，load 1，说明压力增大情况下db的压力反而下来了，注意到nginx服务器的网卡流量达到885M，说明是压力过大情况下，网络满了，发生丢包，导致db端压力反而下来了。

### 5.1.2        改进措施: ###

注意压测情况下部分接口由于数据量传输较大，会出现网络瓶颈。

### 5.1.3        改进效果: ###

## 6        接口名称: 回填接口 ##

## 6.1      压测现象:tps不到500，db的qps3500 ##

### 6.1.1        问题分析: ###

虽然缺少应用的cpu及db的cpu利用率数据，较低的tps应该是应用的瓶颈，且需要关注是不是db在处理查询的时候缓慢。

### 6.1.2        改进措施: ###

1.连接池由dbcp改为hikar；

2.减少了日志打印输出

3.sql优化，将部分条件过滤改为在java代码中执行

### 6.1.3        改进效果: ###