一次JAVA接口优化记录

一次接口优化记录

背景:一个查询文章的接口,有分页,一台二核四G的小服务器。redis也是这台机子搭的单机Redis.
查询速度:QPS在1-10之间。响应速度在一秒以上,可以说是极其的慢了。压力测试直接压到了100秒以上的响应速度。

在这里插入图片描述

首先考虑,添加缓存

缓存策略

缓存策略
步骤:
1、http请求过来
2、根据查询条件,单表走索引查询结果ID
3、根据结果ID去缓存中查询数据,返回结果集
4、判断是否都有缓存,没有的单独拎出来去查询数据库
5、将数据库查询结果添加到缓存中去。
6、将所有结果返回。

方案一:本地缓存

    
 public static ConcurrentHashMap<Long, SysArticle> cache = new ConcurrentHashMap<>();

    private ArrayList<SysArticle> getSysArticlesByMapCache(List<Long> longs){
        List<Long> noHitIdList = new ArrayList<>();
        ArrayList<SysArticle> list = new ArrayList<>();
        // 根据Map从中查找ID
        for (Long aLong : longs) {
            if(cache.containsKey(aLong)){
                list.add(cache.get(aLong));
            }else{
                noHitIdList.add(aLong);
            }
        }
        // 没查询到的从数据库中查询后放入Map
        if (noHitIdList != null &&noHitIdList.size() > 0){
            List<SysArticle> articles = sysArticleService.selectSysArticleByArticleIds(noHitIdList.toArray(new Long[]{}), "");
            list.addAll(articles);
            for (SysArticle a : articles){
                cache.put(a.getArticleId(),a);
            }
        }

        return list;
    }
    }

方案二:Redis缓存

    private ArrayList<SysArticle> getSysArticlesByRedisCache(List<Long> longs) {
        // 文章ID集
        Set idSet = new HashSet();

        for (Long aLong : longs) {
            idSet.add(String.valueOf(aLong));
        }
        // 根据ID集查询redis缓存
        Map<String, Object> articleMap = RedisUtils.getMultiCacheMapValue(CACHE_KEY, idSet);

        // 查看是否有没有缓存的文章,没有则添加到待查询列表
        List<Long> noHitIdList = new ArrayList<>(articleMap.size());
        for (Long id: longs){
            if (!articleMap.containsKey(String.valueOf(id))){
                noHitIdList.add(id);
            }
        }
        
        ArrayList<SysArticle> list = new ArrayList<>();
        for (Map.Entry<String, Object> longObjectEntry : articleMap.entrySet()) {
            list.add((SysArticle) longObjectEntry.getValue());
        }
        if(noHitIdList.size() > 0) { // 找出不存在的缓存,添加进去
            // 根据ID直接查询文章
            List<SysArticle> articles = sysArticleService.selectSysArticleByArticleIds(noHitIdList.toArray(new Long[]{}), "");

            if (articles != null && articles.size() > 0) {
                // 添加到缓存,并且添加到返回列表中
                Map<String, SysArticle> collect = new HashMap<>();
                for (SysArticle a : articles) {
                    collect.put(String.valueOf(a.getArticleId()), a);
                }

                RedisUtils.setCacheMap(CACHE_KEY, collect);
                list.addAll(articles);
            }
        }
        return list;
    }

优化结果

优化结果不明显。可以说是一点都没进步。甚至还退步。
主要还是第三个接口的响应时间过久。
在这里插入图片描述

原因分析:

1、线程池线程数量不足?
2、JVM空间不够,频繁回收?
3、Nginx有限制?
4、Redis性能过差?
5、网络带宽过低?

原因验证

线程池线程数量不足?

扩大线程池数量,发现依旧不变。排除,况且业务并不繁忙,仅是简单的查询数据。

JVM空间不够,频繁回收?

使用率基本不超过20%,也排除。

Nginx有限制?

直接访问ip请求,不走nginx,发现速度也没变化

Redis性能过差?

直接在本机搭建Redis,减少网络带宽。况且redis可是能处理过万的并发。我这才几百。依旧没有变化。

网络带宽过低?

可其他接口访问也不低呀,为啥偏偏你就低。

接口数据分析

在这里插入图片描述

我:突然发现,一个接口返回50多KB。这接口返回的什么呀,这么大,

嗯: 返回了一大段的长文本文子。难怪那么大。

我: 看来也不是非必要数据,去除看看效果。

在这里插入图片描述

将响应数据返回大小减少

在这里插入图片描述

这就很舒服了。。。

等等,我觉得这个10kB还能优化。我记得SpringBoot有一个压缩响应的配置的。再运用看看

compression压缩配置

server:
   compression:
      #是否对响应数据开启gzip压缩,默认false
      enabled: true
      #对指定的响应类型进行压缩,值是数组,用逗号隔开
      mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml

开启压缩后

在这里插入图片描述

再来压测一波

完美(代指这里的小系统)

在这里插入图片描述
在这里插入图片描述

  • 22
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值