本文共 1588 字，大约阅读时间需要 5 分钟。

性能优化的思路：

性能优化一般不会一次性就能满足，可能此处瓶颈消失了，系统一旦运转快速后，在其他地方又发现新的性能瓶颈，所以性能优化需要不断迭代，直至满足性能指标

性能优化的方法：

数据库

很多应用，优化db往往是最直接，最方便，见效最显著的

• 慢查询
• sql执行的扫描行数
• 数据库cpu负载

针对性的解决思路：

• 索引

  正常创建索引
  建立正确的主键和外键

• 分离原则

  读写分离
  业务数据分析
  分库、分表
  主从数据库的配置

• sql查询优化规则

  避免表内的相关子查询
  避免排序或尽可能少的行排序
  大量数据排序时相关数据放在临时表中
  尽量在where后多传查询条件，以减少不必要返回的行
  尽量select只需要的字段,以减少不必要返回的列

• 事务

  保证事务简短
  减少不必要的锁机制

• 数据库业务使用

  如有需要，可以冗余表中字段，避免联合查询
  如有需要，也可以将表内的大字段分离到单独表中，使其单独查询
  必做多表关联时，尽量过滤不符条件表中数据
  数据复杂的表如实时性要求不高，尽量后台任务计算，避免动态查询

redis

redis提供的能力相对比较强，实际单台redis可以提供的qps 4w+

• 单个redis读取和写入耗时长
• redis getconnection时间长
• redis cpu等资源飙高

针对性的解决思路：

• 缓存穿透
  缓存过期时间
• 连接池配置min-idle、max-idle
• 大key、hot key
• 数据缓存机制

JVM

一般jvm表现出来最直接的问题都是gc频繁，cpu波动较大

• fgc和ygc频繁
• cpu居高

针对性的解决思路：

• jvm配置（Xms、-Xmx、Xmn）

日志

日志其实也算是应用层的问题，但是遇到好多次由于日志引起的问题

• 大量日志打印
• 日志锁争抢
• cpu居高

针对性的解决思路：

• 日志异步打印
• log4j2、granfana
• 日志入参打印开关

应用

应用层的问题一般都是在开发设计阶段遗留下来的技术债

1. cpu飙升
   线程频繁切换 - 线程池线程设置
   dubbo连接池线程切换 - dubbo.protocol.threads设置
2. 某些中间件获取等待时间
   db getconnection时间长 - db连接池框架、db连接池配置（initial-size、max-active、min-idle、testOnBorrow、testWhileIdle等）
   redis getconnection时间长 - redis连接池参数配置
3. 频繁操作db或redis
   同一个请求或同一个业务操作前后多次请求相同的数据，数据不复用
   状态更新、计数汇总等业务逻辑直接通过db操作
4. 内存使用不合理
   申请过多的不必要的内存开销
   使用频率较低的大文件，大对象，大数组等使用后未释放
5. 服务间依赖
   依赖第三方服务响应时间过长或崩溃 - 支持异步计算，降低等待时间，设置熔断等措施，考虑延迟加载或提前加载等方式
   应用间频繁通信 - 降低通信次数，缓存常用的，不易变化的数据，选择适当的通信方式比如长连接、短连接
   服务间依赖严重 - 使用消息队列，进行各种应用间进行同步/异步计算

基础组件

因为压测环境基础组件资源、配置或者流量各种原因，特别是从未经过考验的压测环境的基础组件，一般开始阶段都是在长长的链路中各种挣扎

• SLB
• nginx
• ingress
• 网关

问题发现定位方式

• jstack线程快照
• arthas
• 火焰图
• 服务日志
• apm线程分析
• 服务资源监控（cpu、内存、io、gc）
• 中间件资源监控（db、ES、redis、mq等）
• 肉鸡资源监控

转载地址：https://lluozh.blog.csdn.net/article/details/109682146 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！