常见的互联⽹架构中，⼀般都能看到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 改进效果:
Tps由不到500增长为1300多。
7 接⼝名称: 券查询
7.1 压测现象：集结果与单台应⽤结果相⽐不合理
7.1.1 问题分析:
查看是否存在瓶颈资源，可以看到5台tomcat集下，tps为9952，但db的qps为5-6万，cpu利⽤率为37%，说明对数据库进⾏了⼤量的主键或索引查询，⼀般单台db的qps也就4万左右，再增加应⽤的集数量，对tps也不会有太⼤影响。
7.1.2 改进措施:
可以考虑分库
7.1.3 改进效果:
8 接⼝名称: 推荐
8.1 压测现象:nginx长短连接差异
8.1.1 问题分析:
18nginx，2tomcat时tps8100，此时应⽤服务器的端⼝数满，⼀般来说，Nginx短连接在⾼并发下容易
导致端⼝占满的问题。
8.1.2 改进措施:一体化机芯
将nginx改为长连接
8.1.3 改进效果:
tps增长为10733，TPS稳定，起伏减少，但是CPU耗尽。说明cpu打满了，此时如果还要优化就的进⾏代码调优了。
9 接⼝名称: 查询2
9.1 压测现象:18N20T的tps才6842
9.1.1 问题分析:
18台nginx，20台tomcat，tps才6842，此时应⽤cpu利⽤率85%，说明cpu存在瓶颈，但检查此接⼝并未做⼤计算量的⼯作，有可能是⽇志的级别问题，cpu在频繁的打⽇志。
9.1.2 改进措施:
将⽇志级别由debug级改为info级
9.1.3 改进效果:
同等环境tps由6842增长为23592.坑爹的⽣产环境debug⽇志级别。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议