一次接口优化记录

背景：一个查询文章的接口，有分页,一台二核四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<>();// 根据Ｍａｐ从中查找IDfor (Long aLong : longs) {if(cache.containsKey(aLong)){list.add(cache.get(aLong));}else{noHitIdList.add(aLong);}}// 没查询到的从数据库中查询后放入Mapif (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压缩,默认falseenabled: true#对指定的响应类型进行压缩,值是数组,用逗号隔开mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml

开启压缩后

再来压测一波

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