记一次接口性能优化实践总结:优化接口性能的八个建议

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 最近对外接口偶现504超时问题,原因是代码执行时间过长,超过nginx配置的15秒,然后真枪实弹搞了一次接口性能优化。在这里结合优化过程,总结了接口优化的八个要点,希望对大家有帮助呀~

前言

最近对外接口偶现504超时问题,原因是代码执行时间过长,超过nginx配置的15秒,然后真枪实弹搞了一次接口性能优化。在这里结合优化过程,总结了接口优化的八个要点,希望对大家有帮助呀~

  • 数据量比较大,批量操作数据入库
  • 耗时操作考虑异步处理
  • 恰当使用缓存
  • 优化程序逻辑、代码
  • SQL优化
  • 压缩传输内容
  • 考虑使用文件/MQ等其他方式暂存,异步再落地DB
  • 跟产品讨论需求最恰当,最舒服的实现方式

嘻嘻,先看一下我们对外转账接口的大概流程吧

1.数据量比较大,批量操作数据入库

优化前:

优化后:

性能对比:

  • 批量插入性能更好,更加省时间,为什么呢?
打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖(最多放500),你可以选择一次运送一块砖,也可以一次运送500,你觉得哪种方式更方便,时间消耗更少?

2.耗时操作考虑异步处理

耗时操作,考虑用异步处理,这样可以降低接口耗时。本次转账接口优化,匹配联行号的操作耗时有点长,所以优化过程把它移到异步处理了,如下:

优化前:

优化后

匹配联行号的操作异步处理

性能对比:

假设一个联行号匹配6ms

解析:

  • 因为联行号匹配比较耗时,放在异步处理的话,同步联机返回可以省掉这部分时间,大大提升接口性能,并且不会影响到转账主流程功能。
  • 除了这个例子,平时我们类似功能,如用户注册成功后,短信邮件通知,也是可以异步处理的,这个优化建议香饽饽的~
  • 所以,太耗时的操作,在不影响主流程功能的情况下,可以考虑开子线程异步处理的啦。

3.恰当使用缓存

在适当的业务场景,恰当地使用缓存,是可以大大提高接口性能的。这里的缓存包括:Redis,JVM本地缓存,memcached,或者Map等。

这次转账接口,使用到缓存啦,举个简单例子吧~

优化前

以下是输入用户账号,匹配联行号的流程图

优化后:

恰当使用缓存,代替查询DB表,流程图如下:

解析:

  • 把热点数据放到缓存,不用每次查询都去DB拉取,节省了这部分查SQL的耗时,美滋滋呀~
  • 当然,不是什么数据都适合放到缓存的哦,访问比较频繁的热点数据才考虑缓存起来呢~

4. 优化程序逻辑、代码

优化程序逻辑、程序代码,是可以节省耗时的。

我这里就本次的转账接口优化,举个例子吧~

优化前:

优化前,联行号查询了两次(检验参数一次,插入DB前查询一次),如下伪代码:

优化后:

优化后,只在校验参数的时候插叙一次,然后设置到对象里面~ 入库前就不用再查啦,伪代码如下:

解析:

  • 对于优化程序逻辑、代码,是可以降低接口耗时的。以上demo只是一个很简单的例子,就是优化前payeeBankNo查询了两次,但是其实只查一次就可以了。很多时候,我们都知道这个点,但就是到写代码的时候,又忘记了呀~所以,写代码的时候,留点心吧,优化你的程序逻辑、代码哦。
  • 除了以上demo这点,还有其它特点,如优化if复杂的逻辑条件,考虑是否可以调整顺序,或者for循环,是否重复实例化对象等等,这些适当优化,都是可以让你的代码跑得更快的。

之前我这篇文章,也提了几个优化点噢,有兴趣的朋友可以看一下哈~

写代码有这些想法,同事才不会认为你是复制粘贴程序员

5. 优化你的SQL

很多时候,你的接口性能瓶颈就在SQL这里,慢查询需要我们重点关注的点呢。

我们可以通过这些方式优化我们的SQL:

  • 加索引
  • 避免返回不必要的数据
  • 优化sql结构
  • 分库分表
  • 读写分离

有兴趣的朋友可以看一下我这篇文章呢,很详细的SQL优化点:

后端程序员必备:书写高质量SQL的30条建议

6.压缩传输内容

压缩传输内容,文件变得更小,因此传输会更快啦。10M带宽,传输10k的报文,一般比传输1M的会快呀;打个比喻,一匹千里马,它驮着一百斤的货跑得快,还是驮着10斤的货物跑得快呢?

解析:

  • 如果你的接口性能不好,然后传输报文比较大的话,这时候是可以考虑压缩文件内容传输的,最后优化效果可能很不错哦~

7. 考虑使用文件/MQ等其他方式暂存数据,异步再落地DB

如果数据太大,落地数据库实在是慢的话,可以考虑先用文件的方式保存,或者考虑MQ,先落地,再异步保存到数据库~

本次转账接口,如果是并发开启,10个并发度,每个批次1000笔数据,数据库插入会特别耗时,大概10秒左右,这个跟我们公司的数据库同步机制有关,并发情况下,因为优先保证同步,所以并行的插入变成串行啦,就很耗时。

优化前:

优化前,1000笔先落地DB数据库,再异步转账,如下:

优化后:

先保存数据到文件,再异步下载下来,插入数据库,如下:

解析:

  • 如果你的耗时瓶颈就在数据库插入操作这里了,那就考虑文件保存或者MQ或者其他方式暂存吧,文件保存数据,对比一下耗时,有时候会有意想不到的效果哦。

8.跟产品讨论需求最恰当,最舒服的实现方式

这点个人觉得还是很重要的,有些需求需要好好跟产品沟通的。

比如有个用户连麦列表展示的需求,产品说要展示所有的连麦信息,如果一个用户的连麦列表信息好大,你拉取所有连麦数据回来,接口性能就降下来了。如果产品打桩分析,会发现,一般用户看连麦列表,也就看前几页~因此,奸笑,哈哈~ 其实,那个超大分页加载问题也是类似的。即limit +一个超大的数,一般会很慢的~~

总结

本文呢,基于一次对外接口耗时优化的实践,总结了优化接口性能的八个点,希望对大家日常开发有帮助哦~嘻嘻,有兴趣可以逛逛我的github哈,本文会收藏到github里滴哈

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
6月前
|
NoSQL 算法 Java
后端接口性能优化分析-程序结构优化(中)
后端接口性能优化分析-程序结构优化
72 0
|
6月前
|
缓存 NoSQL Java
后端接口性能优化分析-多线程优化(中)
后端接口性能优化分析-多线程优化
129 0
|
6月前
|
消息中间件 存储 监控
后端接口性能优化分析-多线程优化(上)
后端接口性能优化分析-多线程优化
214 0
|
6月前
|
消息中间件 Java 关系型数据库
后端接口性能优化分析
后端接口性能优化分析
116 0
|
6月前
|
SQL 缓存 监控
后端接口性能优化分析-问题发现&问题定义(上)
后端接口性能优化分析-问题发现&问题定义
525 0
|
6月前
|
监控 NoSQL Java
后端接口性能优化分析-问题发现&问题定义(下)
后端接口性能优化分析-问题发现&问题定义
148 0
|
6月前
|
NoSQL Java Redis
后端接口性能优化分析-程序结构优化(上)
后端接口性能优化分析-程序结构优化
201 0
|
6月前
|
SQL 关系型数据库 MySQL
后端接口性能优化分析-数据库优化(上)
后端接口性能优化分析-数据库优化
151 0
|
6月前
|
SQL 关系型数据库 MySQL
后端接口性能优化分析-数据库优化(下)
后端接口性能优化分析-数据库优化
157 1
|
6月前
|
缓存 NoSQL Redis
接口性能优化的小技巧
接口性能优化的小技巧