【性能调优】单接口性能调优预备阶段

最新推荐文章于 2024-04-24 16:34:00 发布

置顶 sysu_lluozh

最新推荐文章于 2024-04-24 16:34:00 发布

阅读量2.7k

点赞数 2

分类专栏： # 性能调优文章标签： java mysql redis 分布式

本文链接：https://blog.csdn.net/lluozh2015/article/details/116461308

版权

性能调优专栏收录该内容

22 篇文章 9 订阅

订阅专栏

一、现状

在性能测试一开始就针对全接口全场景进行性能压测并调优，如果再加上对业务代码不熟悉，基本上就是熟悉的尴尬场景：

阶梯递增并发线程数获得服务性能拐点
调整服务端数据库连接池配置
调整JVM中新生代老年代等配置
优化监控获得的慢sql语句
利用工具分析线程堆栈信息

不了解业务逻辑，不了解具体代码实现，基本上这些招数使用后对于性能优化就毫无头绪且无能为力了

接下来看看调优从开始准备到调优完成整个流程中更为有针对性的方式，需要在调优前更加充分的准备，更加深入的分析业务实现代码，且提前预估性能风险点，有利于接下来的性能优化

二、功能模块

需要熟悉该接口实现的业务功能模块，入参出参以及代表的业务逻辑

三、业务代码

3.1 目的

风险提前暴露
接口性能大概评估
测试场景的设计

3.2 聚焦点

sql或外部接口重复调用
同一个信息在不同的地方重复查询
sql索引命中
索引的规则优化
设计缺陷风险
redis穿透
循环嵌套是否合理for for循环
事务

3.3 统计项

主要是为了统计sql及外部调用的类型和次数，方便大致评估接口性能

统计不同类型sql的次数(读、写)
统计调用外部接口的次数

3.4 日志信息

对象定义中自定义toString()方法，避免序列化，避免直接使用toJsonString(占用30%+内存)

四、中间件

4.1 redis

需注意点

缓存命中率
redis失效时间+随机事件
如果业务可能存在定期刷数据、预热等
回源并发度的控制
某一个key失效时多个线程并发请求导致回源并发压力大
hot key的风险
某个hot key在一台redis中，请求都访问该redis，导致redis负载不均匀
大key的风险

案例代码

@Override
public User getByUidFromCache(String userId) {
    if (StringUtils.isBlank(userId)) {
        return null;
    }
    User user = userRedisService.getByUserUid(userId);
    if (user != null) {
        //表示该用户数据属于活跃数据,延长在redis中的有效时间
        return user;
    }

    user = getByUidFromDB(userId);
    if (user == null) {
        return null;
    }
    LOGGER.info("将用户信息放到缓存中，用户信息为：{}", user);
    //用户信息放到redis缓存中
    userRedisService.put(user);
    return user;
}