大量报表的生成优化办法

前言

一个页面,加载耗时1.3分钟,分析后发现用的O/RM,我记得12306以前爆是因为用的hibernate,而且没用好。

O/RM有各种硬伤,但总是有优化办法。我改进后测试1秒。

痛点

澳大利亚很多政府/企业财年结束(6月30日)便需要进行一些年度操作,譬如给客户发送年度报告等等。

澳大利亚最大的养老金管理也不例外,需要给数百万用户发送一个流水账单(PDF文件格式),根据多年来的观察和官方的说明,一般需要等到9月底到10月初,这意味着需要起码2个月来处理。

分析

简单计算,意味着顺序处理的话,大概每秒完成一个客户,听起来不算慢。

大家会觉得,一年的流水,多则几百条记录,取出来0.4秒,生成PDF是0.5秒,发送0.1秒,那相当合理。

在这个系列操作中,单个业务的瓶颈可能是:

  • 数据获取/计算
  • PDF生成
  • Email发送

优化

最佳的优化,彻底理解业务逻辑后作出相应的改动。在没有理解业务逻辑之前,我们一般提供效率的做法可能有:

  • 分而治之:多个服务器并行操作,每个负责某个用户组,譬如如果有10台机器,那机器1可以处理10%,如此
  • 队列异步:数据获取/计算、生成PDF和Email都分开队列,异步处理,这样每一步的操作不会因为其中一部堵塞后续的操作
  • 内存操作:PDF生成无需写入磁盘再作为附件发送出去
  • 外部资源:邮件发送可以使用第三方的支持异步的服务,譬如Sendgrid,除了独特的功能之外,我们需要的是无阻塞的异步高性能操作

关于数据获取/计算,如果要做优化,可以在设计上做一些改动,譬如加入每月统计,这样到财年末的时候只需要统计过去12个月的月统计便可。而且这些流水如账本那样,只会append only,不会对现有记录进行改动,所以无需考虑重新统计。

另外,单数据库会是性能(还有安全)瓶颈,完全可以把流水/统计数据放到多节点NoSQL里面,取的时候性能优于关系型数据库。

 

当然,还有一些更高级、复杂的优化实践,有兴趣的同学们可以根据右边二维码加我的微信。

 

想知道为什么我这么多年来能掌握那么多种技术,不仅仅是广度,还有深度,达到我所说的“爆栈”吗?

在《爆栈之旅》,我根据大家都实际情况、水平、方向等规划职业路径,手把手带你做实战的项目,用最高效的办法达到你想要的高度。

爆栈之旅

是否想技术水平快速提升?是否希望快速成为公司的技术骨干?

核心价值
  • 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
  • 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
  • 解答各种技术问题
  • 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

发表评论