写点什么

最近被安排搞搜索接口优化,压测了 4 次,才勉强达到要求

用户头像
极客good
关注
发布于: 刚刚

第二次压测


虽然优化了代码,修改了配置,但是情况更糟糕了,而且还改出了新的问题。当时,反复检查了代码,确定查询缓存的次数已经是最少了,而且连接线程池相关参数也调到一个相对较大且合理的值了。如果,再压测还是无法达到要求的话,只有出最后一招了:缓存结果集。即,以用户 ID 和用户搜索的关键词为 key,查询的结果为 value,缓存 5 分钟。

第三次压测


总算符合要求了,并发 60 的时候响应时间达到 32ms,而我又发现了新的优化点。



接口中居然还有查数据库的操作,这可不能忍,排查之后去掉了一些不必要的依赖。

成长

学会了使用 RedisTemplate 的 executePipelined 进行 redis 批量查询


针对本次优化的总结

1、一定要绝对避免循环查数据库和缓存(PS:循环里面就不能有查询缓存,更不能有查询数据库的操作,因为循环的次数没法控制);


2、对于 API 接口的话,一般都是直接查缓存的,没有查数据库的;


3、多用批量查询,少用单条查询,尽量一次查出来;


4、对于使用阿里云,要留意一下相应产品的配置,该花的钱还是得花,同时,千万要记得正式环境中使用相应产品的内网地址;


5、注意连接池大小(包括数据库连接池、Redis 缓存


【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开:qq.cn.hn/FTf 免费领取
复制代码


连接池、线程池);


6、压测的机器上不要部署其它的服务,只跑待压测的服务,避免受其它项目影响;对于线上环境,最好一台机器上只部署一个重要的服务;


7、没有用的以及被注释掉的代码,没有用的依赖最好及时清理掉;


8、集群自不用说;


9、一些监控类的工具工具可以帮助我们更好的定位问题,比如链路跟踪,这次项目中使用了 PinPoint;


10、如果技术上优化的空间已经非常小了,可以试着从业务上着手,用实际的数据说话,可以从日常的访问量,历史访问量数据来说服测试;


11、每一次代码改动都有可能引入新的问题,因此,每次修改代码后都要回归测试一下(PS:每次修改完以后,我都会用几组不同的关键词搜索,然后比对修改前和修改后返回的数据是否一致,这个时候 postman,以及 Beyond compare 就派上用场了);

用户头像

极客good

关注

还未添加个人签名 2021.03.18 加入

还未添加个人简介

评论

发布
暂无评论
最近被安排搞搜索接口优化,压测了4次,才勉强达到要求