赞
踩
财务软件报表还是非常麻烦,因为使用excel最好的就是财务,但是通过java导出excel,使用easyexcel不用报表工具,不是这么容易。采用jprofile对一个导出操作进行监控,其中一家零售企业导出当月全部明细账,检测到工程师编写的这个逻辑执行了2807次。估计很多人难以想想,这种sql是怎么上生产环境的。原因在于如果针对没有多客户的公司,原先的写法是没有问题的,但是针对面向有25万用户的零售企业,这种问题就暴露出来了。
查询条件
导出的报表样式
1 分析需求
有些工程师有洁癖,比如我。别人的代码写不好,干脆重写,而不是改,哪些防御式代码估计工程师本人也未必能看懂。因此第一步是分析需求,而不是看别人代码的的逻辑。
上图分析
2 分析问题
从sql入手,而不是程序入手原因是因为去理解有些工程师的思路,个性化太强,而sql语句至少有一个标准。是理解起来最容易的语言。
下面查看多次执行的sql到底做了些什么?
2.1 acc_account_balance
通过分析可以看到acc_account_balance
分别执行了571、463、108次,合计执行了1142次
2.2 acc_voucher
acc_voucher执行了363、70、55、45,合计553次
2.3 acc_assisting_accounting
acc_assisting_accounting执行了376、51、42次
2.4 acc_account_set
acc_account_set执行了571次
2.5 acc_account_subject
acc_account_subject执行了36次
3 优化思路指引
CompletableFuture
中的任务编排,将所需要的数据加载进来,下面的科目是基础资料,采用二级缓存,这里就不讲了,mysql performance schema 实践,这篇文章我已经讲了从下图可以看到获取数据的时间从50s,下降到268ms,单纯的看数据获取,性能优化了99.47%,速度提升187倍 4.2 组装数据优化
前一个环节只是组装数据,接下来要将这些数据,拼装成excel模板可以用到的数据 。这一款属于业务算法,如果有时间可以重写,但实际改造时间并不会给你太长时间,首先老板会觉得性能优化是员工自身的问题,根本不会在一这个。
我所做的是新建一个v2版本,如果有问题,原来的代码还能用,以免被人诟病,研发工程师内卷,相互轻视的事情也是经常发生的。
接着将上面的数据传入到一个方法中
然后复用之前的一些好的封装逻辑,如果不好可以重写,但还是要注意不要轻易把别人代码删掉,否则那些人有可能会记恨你。
内存中的计算是非常快的,所以筛选也通过流来实现,如下。你会发现你的程序飞快。
因为其他的算法不具备通用性,就不黏贴出来了,但总体思路就是这样,不需要把问题想得太复杂
5 实际效果
导出的sql只需要200多ms,这还是我本地的机器。服务器上更快,这个性能优化已经算是很成功了。
为什么我愿意把这些岁月会计云的优化分享出来,因为技术这东西老板们是不会关心的,这些属于通用性技术,并不像芯片那样具有核心竞争力。有好的经验分享出来,是一种回向。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。