在并发量稍高的情况下提高程序执行效率的举措。

本文分享了一款APP在压力测试中发现的问题及解决方案,包括避免使用嵌套循环、减少数据库交互次数、保持数据类型一致等六个关键点。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言:我们做的app其实也谈不上高并发,压测的时候是用的自己家的测试服务器。标准差不多是10s/2000并发,平均执行时间应该控制在200ms。但是测出来好多不合格接口,这些接口的逻辑,包括sql都再简单不过了。可是测出来的平均执行时间都在5000以上。

优化方案:

1.for嵌套循环尽量(jianjue)不用。特别影响效率。访问量达到一定级别会奔溃。

2.单次请求减少与数据库交互次数。尽量(yiding)把数据集中到一块查询一次。

3.自定bean的时候属性类型尽量和数据库数据类型一致。这个很重要,很致命。由于逆向生成的实体bean不能动,但还要把id加密,这个时候就需要自定义bean了。于是将所有属性类型定义成String。数据库数据在映射到实体的时候还要判断类型是否一致然后不一致还要进行类型转换,消耗了大量时间。后来想了一个办法,不直接映射到实体,先封装到map,这里虽然也涉及到类型查找,但不至于直接映射那么慢。然后转json,然后转实体bean。

List<Map> validTaskListTemp = new ArrayList<Map>();
......装上数据......
String jsonTaskList = JSON.toJSONString(validTaskListTemp);
validTaskList = JSON.parseArray(jsonTaskList, TaskBean.class);

4.sql语句的where后的条件尽量不要加1=1,除非有非必传条件出现,否则坚决不用1=1。

5.where后面先将带索引的必要条件放到前面缩小范围,像deleted,state等等这种不带索引的标记字段往后放。

6.查询数量的时候外连接就别用了,内连接能省则省。

总结:做佛系程序猿。因果循环谁都逃不掉。挖下的坑迟早是要填的。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值