文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

常用的性能优化手段有哪些

2024-04-02 19:55

关注

这篇文章主要介绍“常用的性能优化手段有哪些”,在日常操作中,相信很多人在常用的性能优化手段有哪些问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”常用的性能优化手段有哪些”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

SQL 优化

当你开发的接口响应时间超过了 200ms 的时候就得优化了,当然 200ms 不是绝对值,具体还是看应用场景。以 App 举例,进一个页面调用 5  个接口(题外话:也可以做聚合),那么总共就是 1s 的时间,对用户来说体验还算可以,当然是越快响应越好。

接口耗时 200ms,其中占大头的还是对数据库的操作,一个接口中会有 N 次数据库操作。所以优化 SQL 的速度优先级是最高的,大量的慢 SQL  会拖垮整个系统。

关于 SQL 的优化不是本文的重点,大部分慢 SQL 还是跟各位平时开发时的习惯有关系。大部分在写 SQL  的时候不太会去考虑性能,只要写出来就可以了,join 随手就来,也不梳理查询字段,不加索引,刚开始上线没问题,等到并发量,数据量起来的时候就凉凉了。

关于数据库的使用规范大家可以参考下这篇文章:老大让我整理下公司内部mysql使用规范,分享给大家

当数据量大了后肯定要做读写分离和分库分表的,这也是优化的必经之路。

减少重复调用

性能不好的另一个致命问题就是重复调用,相同的逻辑在不同的方法中重复对数据库查询,重复调用 RPC 服务等。

比如下面的代码:

skuDao.querySkus(productId).stream().map(sku -> {    skuDao.getById(sku.getId()); })

明明数据已经查询出来了,又根据 ID  重新去查询了一次,数量越多,浪费的时间越多。这里只是举例,我相信在真实的项目中大量存在重复查询的情况,之前我还写过一篇文章,讲解如何解决这种重复查询问题,感兴趣的可以查看这篇文章:简直骚操作,ThreadLocal还能当缓存用

按需查询

很多业务逻辑不复杂的功能,却响应很慢。往往都是写代码的时候没有思考,随便就调用一些已经存在的方法,导致整体响应变慢,总结起来就是:性能问题大部分都是代码写出来的。

说个场景,大家肯定都见到过。参数是一个商品 ID,  功能是上架商品,需要进行状态的判断,符合条件才能上架。这个场景下只需要获取商品的状态进行判断即可,有的时候你看到的代码往往都是下面的方式:

GoodsDetail goods = goodsService.detail(id); if (goods.getStatus() == GoodsStatusEnum.XXXX) {  }

detail 中有大量的逻辑,除了基本的商品信息,还有很多其他的内容,这就是慢的原因。

并行调用

针对一个接口,如果设计到多个内部 RPC 服务或者多个外部接口,在接口之间没有关联关系的情况下,我们可以采用并行调用的方式来提高性能。

CompletableFuture 就非常适合并行调用的场景,关于 CompletableFuture 的使用本文不做详细说明,做 Java  的都要会用。

除了 CompletableFuture 之外,对于集合类的处理,可以用 parallelStream 来实现并行调用。

在微服务中有一层专门用于聚合 API,  聚合层就非常适合并行调用,一个功能或者一个页面展示会涉及到多个接口,通过聚合层在后端进行接口的聚合和数据的裁剪,一起响应给前端。

上缓存

缓存也是优化中最常用的,效果提升最明显的,成本也不大。对于缓存,也不要滥用,不是所有场景都可以靠堆缓存来提高性能的。

首先对于实时性要求不高的业务场景可以优先使用缓存,也不用太考虑更新的问题,自然过期就行。

实时性要求高的业务场景,用缓存一定要有完整的缓存更新机制,否则很容易造成业务数据和缓存数据不一致的情况。

建议的做法是订阅 binlog  来统一更新缓存,不要在代码中去更新或者失效缓存,简单的场景还好,入口就那几个,问题不大。有些数据在多个场景下使用,需要更新的入口太多了,

异步处理

有些逻辑,不需要实时反馈给用户那就可以采用异步的方式在后台进行处理。

异步处理的方式最常见的就是将任务加到线程池中进行处理,线程池需要考虑容量以及对一些指标的监控,相关的文章可以查看我的这篇:一时技痒,撸了个动态线程池,源码放Github了

除了一些指标的监控,线程池的使用另一个需要关注的问题就是任务的持久化。如果你的数据本来就是存储好了的,然后读取出来通过线程池去执行是没问题的。如果是没有持久化直接丢入线程池中进行执行,就有可能出现丢失的情况,比如服务重启之类的场景。

关于持久化,无论是线程池还是 EventBus 这种,都会遇到,所以针对异步的场景我建议大家使用消息队列比较好。

消息队列可以存储任务信息,保证不会丢失。单独消费队列的消息进行逻辑处理,如果想提高消费速度,也可以在队列的消费方使用线程池进行多线程消费,多线程消费也要避免消息丢失的情况,可以查看我的这篇文章:嘘!异步事件这样用真的好么?

JVM 参数调整

JVM 参数的调整,一般情况下我们都不用怎么去调整。偶尔有些代码写的不好,导致内存溢出了,这个时候会去做一些调整和优化代码。

参数调整主要是去降低 GC 的导致的停顿问题,如果你的程序一直在 GC, 一直在停顿,你的接口自然就慢了。

只要没有频繁的 Full GC,在优化这块 JVM 的参数调整可以最后再做,优先以 SQL 优化这些为主。

加机器

加机器是最后的终极大招了,并发量上去的时候,你在怎么优化单机器和单数据库抗并发能力也是有限的,这个时候只能水平扩展了。

如果是创业初期,并且在快速发展,加机器是最直接的优化方式了,虽然说成本上去了,但是开发资源也是成本,节约下来可以实现更多的业务需求。等到中期稳定了再考虑架构,性能方面整体的优化和重构。

就像玩游戏一样,有装备的玩家才能所向睥睨啊,对于后端应用来说也是一样,高配的机器,高配的数据库配置,高配的缓存等。

到此,关于“常用的性能优化手段有哪些”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注编程网网站,小编会继续努力为大家带来更多实用的文章!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-前端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯