|
<< Click to Display Table of Contents >> 设计高性能的报告复制链接 |
1.前情提要
1)直连数据库情况下，报告需要发送查询到数据库中执行数据，如果SQL在数据库里本身执行很慢，则报告执行也会很慢。如果数据集本身比较慢，则基于这个数据集创建的报告也会慢。
2)如果测试环境开发的报告本身比较慢，别指望上到生产环境后，利用生产环境的高配置能改善报告的打开速度，生产环境有优先级更高的报告需要确保打开速度，有更多的并发用户需要支持。
3)尽量将永洪升级到最新的稳定版本，永洪一直在致力优化产品架构，提升产品性能和稳定性，有一些影响性能问题的点，在vividime最新版本中已经解决掉，这些问题由于架构的原因在老版本中可能无法处理。
4)不要把所有的内容都放到一个大而全的报告中，也不要一个报告中的不同组件都绑定不同的数据集，如果一个报告就要发送1000个查询，很明显它的性能肯定不会好。在性能和数据呈现上，需要遵行性能优先原则，请一定要简化报告，通过制作的手段引导客户查看不同的报告进行递进式的分析。
5)如果一个表格或图表包含几十万或数百万的数据，需要占用大量的CPU和内存，最差的情况下会导致耗尽内存从而宕机。当然，可以向服务器加更多的内存来解决这个问题，但是缺治标不治本。请一定要留意交叉表、自由式表格、散点图、热力图等的制作。
2. 报告端性能最佳实践
1)避免大量明细数据的导出。
2)数据集上的样本行数避免选择全量数据，这样会导致在编辑报告时每次计算都用全量数据。
3)报表避免展现全量数据，最好通过过滤组件或参数组件设置默认值进行过滤，展示部分默认数据。更不要把所有明细行数据不做任何过滤地一次性加载在报告上，占用大量内存资源，也不利于分析，造成系统资源占用巨大。建议把用户最关心的数据过滤呈现出来，比如用Top N的模式或者加上默认时间等筛选条件，对数据进行有效过滤后展示。
4)有多个筛选条件时，推荐使用批量提交，而不是每次筛选都提交一次。
当页面过滤组件超过4个时，尽量使用参数组件+批量提交组件方式替代。
过滤组件每次进行选择都会自动提交刷新请求，经常造成无效查询，浪费系统资源，建议当查询条件较多时，采用上述参数组件+批量提交的方式代替。
5)多个过滤组件的数据来自同一个数据集时，会计算组件之间的联动关系，所以不要随意调高list.qry.maxrow的值。
6)如果宽表的数据量很大，建议通过参数组件进行筛选，参数组件绑定维表的字段。
7)无特殊情况，不设置组件的间隔刷新，且间隔刷新频率应该不小于1分钟（60秒）。间隔刷新，其实是发送http请求更新数据，如果设置间隔刷新的组件有多个，且刷新频率高，会触发大量的http请求，导致页面卡顿，且影响其他页面的正常打开。
8)一些使用自由式表格的隔间计算场景，实际上通过计算列一样可以计算出来。对于交叉表和自由式表格，期望汇总后的数据量不要太大。能够用简单表或交叉表实现的场景就不要使用自由式表格。
9)报告多页签标签页数不超过6个。
由于各标签页在加载时，如果有使用相同的过滤器参数或其他数据依赖关系，都会提前进行数据加载，影响数据加载性能，所以不要设置超过6个。如需此功能，可采用超链接的方式分割报告的内容，避免此类现象。
10)控制报告背景图片的大小，不超过100KB。
11)影响性能的属性配置：
•join.grid.maxrow=10000000（默认1000万），后期处理的join，数据行数超过最大值后预警提示，建议默认设置小点例如100000，尤其是给大量业务用户使用时。
•max.load.rows=5000000（默认5000万），设置组件默认加载的数据行数，不影响导出，导出的数据为全量数据。
•max.export.control=true，控制报表和组件默认导出的数据行数。默认true代表控制导出，设置成false表示不控制导出数据量。跟随max.load.rows的查询逻辑，查询能控制量的地方导出都能控制住。
•参数配置：
_REFRESH_：直连数据库时，如果设置为true，每次查询都会访问数据库数据，而不会走缓存。
_M_REFRESH_：如果设置为true，对于物化了的数据集，不会走集市，而是走数据库计算。