侧边栏壁纸
  • 累计撰写 10 篇文章
  • 累计创建 9 个标签
  • 累计收到 4 条评论

目 录CONTENT

文章目录

Web系统性能速度优化五部曲

老七云运管002
2022-02-06 / 0 评论 / 1 点赞 / 381 阅读 / 2,235 字
温馨提示:
本文最后更新于 2022-02-06,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

Web系统性能速度优化五部曲

  • 其实无论做什么系统,性能和速度的优化无非是,在同一时间尽可能多的去处理业务逻辑,其中起到作用较高的,不外乎,多线程,缓存,消息中间件,下面就为大家介绍一下常见的五中优化方式。

1. 异步线程

工作几年后发现,只要想提高程序的性能,就绕不开多线程。最常见的场景,就是利用多线程并发执行多个局部事件,缩短总体完成时间。开发中,通常整个项目注册一个线程池的 Bean,各个方法都基于这个线程池来拿线程执行业务,容易针对线程池做参数调优。

有返回参数的异步,可以试试 CompletableFuture,也是 jdk8 提供的神器,比传统的 Feature 要好用,用法参考 CompletableFuture 教程。例如:当接口需要从多个外部系统取数据时,都可以异步执行,然后统一收集返回值。甚至利用 CompletableFuture 中特性,自动执行回调方法。

但要注意,也不是什么时候都要用异步:

  • 机器 CPU 资源有限:单台机器 CPU 的核心数有限,当多线程并发数达到顶点时,再加线程,反倒适得其反。此时可以考虑负载均衡,将并发线程分摊到多台机器上。
  • 同步更快:有些程序原本执行就很快,加了异步后反而慢了,毕竟分配线程资源也是需要时间的。例如总共只有十几条数据,流运算时不用 stream,而是 parallelStream

2. 缓存中间件

Redis

Redis 是最常用的缓存中间件了,它支持的常用数据结构挺多,要根据实际应用场景来选择,目前常用的有String、Hash、Set、List。

原始数据当然落在关系数据库中,但业务上常用的,通常是经过转化的中间数据。例如:员工登录后所属部门、角色权限、积分等数据,来自于不同的微服务,不能每次要用都调各方服务的接口,这些都需要缓存起来。

用缓存很无脑,但刷新缓存才是难题。像刚刚的例子,不能把所有的缓存数据都落到员工的粒度上,要根据业务来分层。例如:机构级别的数据,就每个机构存一份,按照员工所属机构来查;部门级别的数据,就每个部门存一份,按照员工所属部门来查。等等。

Elastic Search

用 ES 做缓存?估计很多人是大大的问号,谁让 Redis 当时不支持 Json 呢。从关系型数据库抽离出来的数据有时比较复杂,例如:人员所属的部门、角色、岗位等,每一个属性往下,背后的数据都不少。有人说 Redis 缓存个部门ID、角色ID,剩下的根据ID查表。但这些可是基础数据,且不说会不会把数据库查出问题,如果想要根据部门属性、角色属性、岗位属性来查人员,这个SQL该咋写。

最好的方式就是将这些数据从关系数据库中抽出来,以 Json 文档的形式缓存下来,MongoDB、ES 都能干这事。但为了应对后续可能千奇百怪的查询场景,还是 ES 保险一些。

可 ES 毕竟不是专业的缓存中间件,我很看好最近新出来的 RedisJson。完全满足日常工作需求,而且据说查询性能是 ES 的上百倍。

3. 消息中间件

这里不说 MQ 的其他特性,就聊优化性能吧。前面说单台机器的 CPU 资源有限,可以考虑将并发线程分摊到多台机器上,具体怎么做呢?

将需要处理任务通过消息投递到 MQ 中,消费者监听到 MQ 的消息后实际执行。倘若有1000个任务,单台机器能处理任务的最大并发线程数是100,那么10台机器就够了。

4. 减少系统交互

内存运算是最快的,要尽量减少和外部系统的交互次数。

例如:在查询一批数据时,每条数据需要通过外键,查询匹配的其他系统信息。如果其他系统信息种类不多的话,是不是通过查一次SQL或调用一次接口,一次性全拿过来。然后写代码做数据拼接。而不是遍历出每条数据,都去外部系统查一遍。

还有一些插入 MySQL、Redis 的一批数据,或给 MQ 发一批消息的,如果可以的话,就在程序内部处理好,然后调用批量插入、发送的方法,性能绝对能省不少。

5. Jvm 调优

jvm调优常见手段

  1. 堆内存监控 空间大小分配(年轻代、年老代、持久代分配)

    有了堆信息查看方面的功能,我们一般可以顺利解决以下问题:

    1. 年老代年轻代大小划分是否合理
    2. 内存泄漏
    3. 垃圾回收算法设置是否合理
  2. 线程监控 (线程信息监控:系统线程数量。线程状态监控:各个线程都处在什么样的状态下)

热点分析

  1. CPU热点:检查系统哪些方法占用的大量CPU时间

  2. 内存热点:检查哪些对象在系统中数量最大(一定时间内存活对象和销毁对象一起统计)

  3. 快照

    快照是系统运行到某一时刻的一个定格。在我们进行调优的时候,不可能用眼睛去跟踪所有系统变化,依赖快照功能,我们就可以进行系统两个不同运行时刻,对象(或类、线程等)的不同,以便快速找到问题

    举例说,我要检查系统进行垃圾回收以后,是否还有该收回的对象被遗漏下来的了。那么,我可以在进行垃圾回收前后,分别进行一次堆情况的快照,然后对比两次快照的对象情况。

  4. 内存泄漏检查

    内存泄漏是比较常见的问题,而且解决方法也比较通用,这里可以重点说一下,而线程、热点方面的问题则是具体问题具体分析了。

    内存泄漏一般可以理解为系统资源(各方面的资源,堆、栈、线程等)在错误使用的情况下,导致使用完毕的资源无法回收(或没有回收),从而导致新的资源分配请求无法完成,引起系统错误。

    内存泄漏对系统危害比较大,因为他可以直接导致系统的崩溃。

    需要区别一下,内存泄漏和系统超负荷两者是有区别的,虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误,而系统超负荷则是系统确实没有那么多资源可以分配了(其他的资源都在使用)。

文章转载自:https://www.l7y.cn/

1

评论区