永洪社区

标题: 其他系统引用永洪的报告，第一次点击菜单后加载很慢 [打印本页]
作者: yhdata_Ooc9mAXq    时间: 2022-1-22 19:18
标题: 其他系统引用永洪的报告，第一次点击菜单后加载很慢
同样的一个报告，1）数据集的sql复杂时需要5到6秒；超过1秒的接口一般都是https://c.clamc.com/bi/Viewer?isAjax=true&proc=1&platform=PC&deviceType=16&action=req&__level1__=viewer
该接口有时甚至超过10秒
2）将sql落地，数据集仅一个select的简单查询时，上面的接口没有超过1秒的了，但是页面展示出数据仍需要4到5秒，怎么才能再快点？


上述将sql落地，仅仅快了1秒，是否有其他方式使得页面加载更快？


作者: humming    时间: 2022-1-22 19:18
嗯，这个就是新的查询，和2020年的那个缓存的key是不同的。 这种情况很快我猜测是你的报告打开的时候，有很多组件的数据需要执行，但是你修改参数的时候，只是受到这个参数影响的部分需要执行，不受参数影响的就不会再次执行了，所以比较快。
作者: yonghongtech-小洋人    时间: 2022-1-22 19:27
直连的报表打开速度取决于对应数据库执行sql以及返回数据的快慢。接下来咱们讲一下如果一个报表慢，咱们如何判断是否是sql执行慢导致的，以及这种情况该如何优化。
1.如何判断一个直连的报表，慢在哪里
原理：从日志中判断，一个报告打开花了多长时间，时间花在哪里
（1）首先打开相关debug，位置：管理系统-系统参数配置-调试信息参数配置，将performance.debug设置为true

（2）新建日志文件（管理系统-日志管理）

（3）清理系统缓存（管理系统-系统设置-清除系统缓存）


（4）记录大概时间，然后去查看报告打开对应报表。报表加载完成后，下载日志到本地分析
（5）通过Notepad++打开bi.log
A.搜索“Create dashboard”，并对照之前记录的时间以及咱们打开的报表的名称，找到咱们这次打开报表对应的唯一ID。比如我这里的报表名是：“coffee_test”，唯一ID是“coffee_test20210130173614-693”

B.搜索“first page area”找到这次报表打开花的时间。比如这里的215516ms=215s=3.6min

C.然后搜索步骤A中找到的唯一ID：“coffee_test20210130173614-693”，从搜索结果中找到花时间最长的查询。

后面紧跟的sql就是执行慢的sql,花了214990ms=3.58min，这个时间跟报表打开时间进行对比，可以确认这个报表就是慢在这里，实际报表中可以不只是一个地方慢，凡是时间比较长的都需要看看。
sql:
SELECT `交易时间`, `产品名称`, COUNT(DISTINCT `利润`) AS LONG_COL_0, COUNT(DISTINCT `区域代码`) AS LONG_COL_1, COUNT(DISTINCT `市场开销`) AS LONG_COL_2
, COUNT(DISTINCT `总成本`) AS LONG_COL_3, COUNT(DISTINCT `订单ID`) AS LONG_COL_4, COUNT(DISTINCT `边际利润`) AS LONG_COL_5, COUNT(DISTINCT `销售额`) AS LONG_COL_6
FROM coffee_test
GROUP BY `交易时间`, `产品名称`
ORDER BY `交易时间` ASC, `产品名称` ASC
LIMIT 5000000
D.在数据库执行一下这个sql看看花费时长。这里的时长不一定跟日志中记录的完全一样，但是应该可以明显的看出来数据库执行sql慢。

2.对于上述这种数据库执行sql慢导致的报表打开慢的问题，可以尝试的解决方式如下：
（1）如果有购买集市这个模块，且数据对实时性要求不是太高，可以考虑将数据集入集市。入集市后查看报告就不再走数据库实时查询，而是走集市查询，集市采取列存储，有加速的作用。
比如咱们之前的报告，入集市后查询速度提升很多。
2021-02-02 17:19:42.416 |-admin-4adaec56b4e04134a67c6ef563fb25de |-[INFO] |-g5.db.RTDashboard.checkPendings(RTDashboard.java:740) | Open db coffee_test20210202171941-1491 first page area cost 749
备注：入集市后理论上有优化，优化的情况要看实际情况，不是一个固定的。
（2）如果报告上针对全局进行的过滤，可以考虑将过滤放到sql数据集的sql中进行，另外对数据库进行优化也是必须的，效果更佳明显
参考：https://yonghongtechonline.udesk.cn/question/226409
作者: yhdata_Ooc9mAXq    时间: 2022-1-23 21:54
为什么只是第一次查的时候慢，后续查的速度还可以？第一次不能和后续一样吗？
作者: 环环    时间: 2022-1-24 10:45
第一次是指每次重新打开报告，还是制作报告后第一次查看
作者: yhdata_Ooc9mAXq    时间: 2022-1-24 21:57
我们前端引用了报告
每天早上在浏览器我们自己项目里点击这个报告的菜单，这就是第一次，这次非常慢，后续重复来回点都不慢
作者: 美滋滋    时间: 2022-1-24 22:40
那是有缓存机制
作者: yhdata_Ooc9mAXq    时间: 2022-1-24 23:03
那第一次为什么没缓存？我可以提工单让第一次也加缓存吗？
刚才看到有很多接口第19秒以后才开始，这个接口后面的开始都很晚
他前面的接口都挺正常的，都是几百毫秒以后就开始的
作者: 永洪tech-Bella    时间: 2022-1-25 09:28
yhdata_Ooc9mAXq 发表于 2022-1-24 23:03
那第一次为什么没缓存？我可以提工单让第一次也加缓存吗？
刚才看到有很多接口第19秒以后才开始，这个接口 ...

第一次打开报告没有缓存是正常的，第一次打开过后，后续打开才可能走缓存的。
如果咱们觉得某个报告特别慢，可以将performance.debug设置为true，然后清理系统和浏览器缓存，打开报告。然后提供这段时间的bi.log，以及将报告从资源部署导出。提供bi.log和报告，咱们通过日志具体分析一下。
(, 下载次数: 470)