呕血回顾一次提高接口并发的经历，很实用

技术分享 1年前 (2023-09-25) 0 999+

最近在开发一个打卡接口，其实只需要做些判断，保存一下打卡结果即可，预计同时段1000多人在线打卡，但是第一次写完之后，压测效果非常糟糕，可以看到只有十几的并发，喝下的水都要喷出来了，那么简单的接口都能耗时那么久的吗，我预估100ms以内准可以的，那还有上百的并发才对。于是开始了我的优化之路。

看看主要代码，controller接收参数进来之后，执行一下服务方法就返回了，就是查询活动，判断活动时间，累计积分，保存结果，并发这么差我实属是想不到，让人摇头摇头郁闷，我应该没问题啊，部署的机器有问题？但是也都是还可以的服务器的。

  @Override   public RelationActivityRecord clock(String userId, ClockDto clockDto) {     // 判断活动是否有效     RelationActivity relationActivity =         relationActivityService.getRelationActivity(clockDto.getActivityId(),                 clockDto.getActivityType());     Date now = new Date();     if (now.before(relationActivity.getStartTime())) {       throw new BadRequestException(ErrorEnum.WRONG_ARGUMENTS, "活动还未开始，请耐心等待~");     }     if (now.after(relationActivity.getEndTime())) {       throw new BadRequestException(ErrorEnum.WRONG_ARGUMENTS, "活动已结束，可在主页查看个人作品哦~");     }     // 本次打卡获得积分     int score= 0;     // 当天的0点时间     Date toDay = DateUtil.beginOfDay(now);     if (Objects.equals(clockDto.getActivityType(), 1)         && Objects.equals(clockDto.getClockType(), 1)) {       // 查询累计打卡次数       CurrentClockRecordVo clockRecordStat = this.currentRecord(userId,               clockDto.getActivityId(), clockDto.getActivityType(),                );       // 当天第一次的打卡，可以攒一个积分       if (clockRecordStat.getLastTime() != null && clockRecordStat.getLastTime().before(toDay)               && clockRecordStat.getNum() < 100) {         score = 1;       }     } else if (Objects.equals(clockDto.getActivityType(), 1)) {       // 其他的活动之类...       throw new BadRequestException(ErrorEnum.WRONG_ARGUMENTS, "活动暂未开放");     } else {       throw new BadRequestException(ErrorEnum.WRONG_ARGUMENTS, "未知活动");     }     // 保存打卡记录     RelationActivityRecord newClockRecord = new RelationActivityRecord();     newClockRecord.setStudentId(userId);     newClockRecord.setActivityId(clockDto.getActivityId());     newClockRecord.setActivityType(clockDto.getActivityType());     newClockRecord.setClockType(clockDto.getClockType());     newClockRecord.setCreateTime(now);     newClockRecord.setContent(clockDto.getContent());     newClockRecord.setEnergy(energy);     newClockRecord.setVideoId(clockDto.getVideoId());     newClockRecord.setIntro(clockDto.getIntro());     this.save(newClockRecord);     // 有积分可以攒到学生账户上     if (score> 0) {       activityStudentService.addScore(clockDto.getActivityId(), userId, score);     }     return newClockRecord;   }

冷静冷静再次喝口水，遇到问题先找找外部原因，是不是springboot默认的tomcat最大连接数之类的默认值太小，项目里是没有重新配置的，但是一想前些天看过一个视频说，默认的都是8192最大连接数，那不改配置也是嘎嘎够用的。谨慎起见，写一个随便执行几条语句，不连接数据库的接口压测一下，一开始有1000多并发，然后积攒的排队请求多了之后，并发逐渐下降到600，正常合理，处理不过的请求会排队没办法，除非加大线程数的配置：

突然想起来，项目启动不是用的tomcat，而是更换成了undertow，这家伙有问题吗？但是求助搜索引擎，说它要比tomcat更彪悍，至少默认是有8000并发的，看来也排除了。

那会不会是JVM的堆栈设置的太小，处理卡顿，看了下gc数是有点多。其他项目拷贝过来的启动配置，才512M我去，马上改成4G试试。然而，实际效果并无变化。其实gc虽然很多，但实际耗费的时间加起来都没3s，可以排除是它的问题。（这里还遇到了一个问题，就是即使改大了之后，项目一次启动还是会有3次full-gc和几次的young-gc，一下子搞不懂为什么会这样，有经验的朋友可以给些排查方向）

为此，我判断大概率是接口耗时太久导致并发起不来。

代码除了一些判断语句，对象转换，查询插入更新数据库，就没有其他操作了。对象转换有问题吗，但是通篇都有对象转换，这都有问题可能吗。估计真的是数据库有问题了。为了提高查询速度，我只加了一个复合索引，这都那么慢是很不符合常理的。

那我就用skywalking探测一下！

这。。真的是接口耗时符非常久，虽然压测情况下，分配资源出来等了70ms，但接口执行的时候却花费了308ms，在skywalking怎么只能看到查询语句的耗时，可是查询语句只花了几毫秒而已。

那我加下p6spy看下，每条语句的执行耗时吧。

吃惊，吓人，这两插入更新语句居然需要两百毫秒。

咋回事，我想想，想不通，求助搜索引擎和大模型了：

留意到第2点，没有想到，我本来认为接口可以忍受不加事务带来数据不一致性，以提高并发。既然这么说了，那就加个事务试试。不加不知道，一加吓一跳，加了基本0耗时了。

再搜索一下这是为什么，有人说是加了事务之后，不会像之前一样插入一次写一次盘，然后在事务的干预下，攒够一批再写盘，这样效率就高了。那这里或者还能优化这一批能不能攒多点，也要衡量涉及到写盘的时候，当时的单个接口请求就会慢了。

然后有了另一个疑问，我事务是不是加得太大了，毕竟是先查询，再插入和更新数据，可以将它们分开的，那就分开试试，查询不加事务，插入更新提出一个方法加事务，但是，奇了怪了，结果并发效果更差了。看来这里面还有事。同时发现这里一开始压测都压同一个用户，按理说真实情况是不同用户的，同一个用户可能竞争资源更加剧烈，所以对获取用户userId改了一下随机生成一个。

这个时候感觉到8.x版本的skywalking实在是很难提供到更全面的消耗信息，想到不久前看到skywalking9.x版本来了，那就下载一个试试吧。这里我一开始下载了最新的版本，结果死活启动不了一直闪退，什么端口占用啊都改了也不行，大坑。然后直接选9.0版本，就正常启动了。果然9.0版本就不一样了，界面布局舒服了，监控数据也活了，很赞。

而且，trace链路的耗时发布总算是全面了很多！！数据库连接都出来了。可以看到，看了下没有加事务之前，每次查询，写入，都要单独获取一次数据库链接！！！插入语句监控也能正常出来了！

查询不加事务，查询和更新用了事务，得获取三次数据库连接，第一次连接是为了查selelct 1判断数据库是否正常，可以去掉。

查询和插入更新在同一个大事务，只获取一次数据库连接，效率自然更高了。

这里基本也确定了，放一个事务里，效率要高，减少获取数据库连接。

此外，通过查看 skywalking链接追踪，发现是getConnection的时候特别耗时，获取一个连接要好几秒。

目前连接池用的是druid，参数是默认配置，查了下默认配置的最大连接数并不高，那问题估计就是这里了，加大试试。目前pg数据库设置是250个链接，如果是生产环境，数据库独享，yml和pg配置的最大连接数还能大些，目前先试试200，如果并发能提高说明这里也是能优化的点，当然实际配置还得看情况，不然会把数据库拉胯。