java员 基类循环调用show方法 java循环调用接口优化

目录

• 一次接口优化记录

• 首先考虑，添加缓存

• 缓存策略
• 方案一：本地缓存
• 方案二：Redis缓存

• 优化结果

• 原因分析：
• 原因验证

• 接口数据分析

• 将响应数据返回大小减少
• compression压缩配置
• 完美（代指这里的小系统）

一次接口优化记录

背景：一个查询文章的接口，有分页,一台二核四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<>();
        // 根据Ｍａｐ从中查找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

开启压缩后

再来压测一波

完美（代指这里的小系统）