1.1 应用场景

在使用填报过程中，可能会出现一些性能问题，比如提交慢，页面加载慢，导入 Excel 慢，控件操作卡顿等。本文档针对这些常见场景，结合产品现有的逻辑进行分析，帮助大家更好的发现和解决填报性能问题。

问题描述：

填报预览的页面，相较于分页预览方式，加载时间明显变长。

填报预览的页面，插入删除行时加载较慢。

注：如果分页预览加载也慢，可以参考模板性能问题排查方法排查。

2.1 数据量过大

原因分析：

由于填报预览默认不分页，所有数据和元素都在一个页面上展示。所以当数据量较大时，页面元素也会很多， 就有可能造成页面加载慢。

解决方案：

1）通过查询条件控制每次查询的数据量

2）使用「填报分页」功能

2.2 控件直接显示

原因分析：

开启「直接显示控件」功能后，会明显增加浏览器的渲染压力。

此外，如果单元格控件存在数据字典且有默认值，则每一个控件都会在页面加载时发送请求去获取数据字典信息，导致加载缓慢。

注：例如按钮控件、复选按钮控件、单元格按钮组控件等，不会受到「直接显示控件」设置的影响，默认始终直接显示，会出现上述问题。

解决方案：

1）关闭「直接显示控件」，尽量不使用按钮控件、复选按钮控件、单元格按钮组控件

2）通过查询条件控制每次查询的数据量

3）使用「填报分页」功能

4）不设置单元格控件的默认值

2.3 页面使用了 sql()、ds1.select()、value() 等取数函数

原因分析：

同条件下，取数函数的性能排名为：value()>ds1.select()>sql()，如果使用了性能较差的函数，且数据量较大的话，会造成页面加载缓慢。

解决方案：

1）优化 sql 本身的速度

2）使用 value() 函数

3）通过查询条件控制每次查询的数据量

4）使用「抽数缓存」优化取数速度

2.4 插入行局部刷新

11.0.2 版本开始，支持通过在url后添加参数 &async_insert=true 开启插入行后局部刷新，能有效提升大数据量时的插入行速度。

问题描述：

控件在输入值或者选择值之后，页面会长时间卡顿。

3.1 控件数据字典数据量大

原因分析：

带有数据字典设置的控件，如果数据量较大，模糊搜索就会比较慢。

解决方案：

参考下拉框数据量大时模糊搜索慢的方案处理。 

3.2 控件存在联动

原因分析：

如果控件输入数据后，需要联动其他控件数据字典/单元格或者写了 JS 进行一些自定义处理，而被联动的内容较慢的话，就会导致卡顿。

解决方案：

1）优化被联动的内容，减少多余的联动设置。如需要使用取数函数，尽可能用 value() 函数。同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。

2）使用「抽数缓存」优化取数速度 

3）如果是用JS给其他单元格赋值，且赋值的数据量较多，可以换用批量赋值接口，具体用法可参考：JS实现复选按钮控件全选和批量操作中的2.5一节

3.3 控件值校验慢

原因分析：

带有数据字典设置的控件，设置了「不允许自定义值」后，每次输入值都会触发该校验，去对应的数据字典搜索。如果数据量大，就会导致卡顿。

解决方案：

勾选「允许自定义值」，并将相关校验放在「填报属性」的「数据校验」设置中实现。

问题描述：

点击数据校验，页面卡住无响应。

Excel 批量导入速度慢（Excel 批量导入包括了校验和提交2个过程）。

4.1 数据校验过多/过于复杂

原因分析：

在数据量较大的情况下，如果设置了较多/较复杂的校验公式，例如包含层次坐标，取数函数(sql()、ds1.select()、value()等)的公式，就会导致校验卡顿。

解决方案：

1）同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。在条件允许的情况下，尽量使用value函数来取数，同时优化数据集sql本身的执行速度。

2）使用 「抽数缓存」优化取数速度

3）在校验公式无法简化和减少的情况下，可以考虑分批次提交数据，减少每次提交的数据量。

4.2 不符合校验条件的数据过多

原因分析：

存在不符合校验条件的数据时，系统会标注出对应的单元格，方便用户识别和修改。但如果不符合的数据太多，标注过程会占用较多渲染性能，造成页面卡顿。

解决方案：

此情况较少，可使用「填报分页」优化，但分页后不符合校验的标记只对当前页生效。

4.3 控件的自定义值校验慢

原因分析：

11.0.2版本开始，点击数据校验或者提交时，会校验所有控件的「允许自定义值」设置。当控件数据字典中的数据量较大时，该校验过程会占用比较多的时间。

解决方案：

1）如果不需要在提交时校验控件的「允许自定义值」设置，可以在finedb的FINE_CONF_ENTITY表中添加字段WriteOptimizationConfig.verifyCustomValue=false来回退逻辑，使得提交时不再校验该项设置。

2）如果需要在提交时校验控件的「允许自定义值」设置，目前没有特别好的方案，可以考虑减少数据字典的数据量，或者将相关校验放在「填报属性」的「数据校验」设置中实现。

问题描述：

点击数据校验速度较快，但点击提交速度较慢。页面一直显示加载中，甚至崩溃无响应。

Excel 批量导入速度慢（Excel 批量导入包括了校验和提交2个过程）。

5.1 数据量建议

原因分析：

在服务器硬件较好，且填报模板为简单结构的情况下，目前能支持的提交数据量（行*列）上限在100w左右。在此范围内，数据量越多，提交的时间也越长。

解决方案：

尽量控制一次提交的数据在100w内。如果超出了，可以考虑分批次提交，减少每次提交的数据量。

5.2 数据表已有数据影响了更新和删除速度

原因分析：

当提交类型为智能提交、删除提交、更新提交时，在执行提交过程中会发送带有where关键词的sql语句去根据主键找到对应数据，所以如果数据表已有部分数据，则该查询动作可能耗时较长，影响整个提交的速度。

解决方案：

1）如果只需要插入数据，将提交类型改为插入提交。

2）如果需要更新和删除数据，则根据填报属性中设置的主键，去数据库给对应字段增加索引。索引覆盖的字段数量和顺序都需要和填报主键字段一致，否则无法发挥效果。（优先推荐）

注：可通过测试插入提交的速度来确认问题原因是否为此项，如果同样数据插入提交较快，其他提交较慢，则大概率为此原因。

5.3 数据库自身存在性能问题

原因分析：

如果数据库本身性能不是很好，也会影响提交速度。

解决方案：

1）优化数据库设置

2）更换数据库

3）若入库的数据库类型为 MySql，可以通过在 MySql 数据连接的 URL 后增加 rewriteBatchedStatements=true参数来开启 MySql 数据库的批量提交功能，从而提高提交性能。格式如下：

若 URL 中未添加过参数，直接加 ?rewriteBatchedStatements=true

若 URL 中已添加过参数，最后加 &rewriteBatchedStatements=true

5.4 数据库表被锁

原因分析：

如果提交入库的表因为某些原因被锁了，则可能导致长时间提交不入库。此时日志中会出现类似于Lock wait timeout exceeded等带有lock的报错。

解决方案：

在数据库检查入库表是否被锁，解锁后再提交。

5.5 页面数据存在笛卡尔积

原因分析：

模板父子格设置不合理，造成数据以数组*数组形式提交，提升了提交的数据量和时间。

出现此问题时，提交时页面会提示存在笛卡尔积，日志中也会出现BatchDML,one of FArray的提示。

解决方案：

根据报错中提示的字段，调整其所在单元格的父子格关系。不建议开启「允许填报笛卡尔积」，其并不能提升性能。

问题描述：

导入 Excel 时间较长，甚至页面崩溃无响应。

6.1 渲染慢

原因分析：

导入数据量大时，会明显增加浏览器的渲染压力。且如果开启了「直接显示控件」，则会进一步增加渲染压力，导致导入缓慢。

注：例如按钮控件、复选按钮控件、单元格按钮组控件等，不会受到「直接显示控件」设置的影响，默认始终直接显示，会出现上述问题。

导入时可以通过以下加载动画的时间来确认是由于渲染慢导致。

解决方案：

1）使用「填报分页」功能进行预览和导入 （优先推荐）

2）关闭「直接显示控件」，尽量不使用按钮控件、复选按钮控件、单元格按钮组控件

6.2 计算慢

原因分析：

在导入时，会对页面上的公式进行计算。如果公式复杂，或者涉及取数函数（sql()、ds1.select()、value()等）的话，则可能会影响导入速度。

导入时可以通过以下加载动画的时间来确认是由于计算慢导致。

解决方案：

1）同条件下，取数函数的性能排名为：value()>ds1.select()>sql()。在条件允许的情况下，尽量使用value函数来取数，同时优化数据集sql本身的执行速度。

2）减少需要在页面上计算的公式数量，降低其计算复杂度。

3）使用「抽数缓存」优化取数速度 。