前言
一个页面,加载耗时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个人指导、代码审阅等
-
解答各种技术问题
-
为公司提供技术解决方案
请查看本站右边的信息联系我。
版权所有
所有文章内容版权所有,任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。