优先推荐
用户向管理员反馈，感觉系统使用卡慢，此时管理员会遭遇以下困境：
1）无法衡量和定位问题
2）需要被动的等待用户反馈问题
因此帆软推出「FineOps运维平台（为企业提供帆软应用稳定运行和全方位运维管理的解决方案）」，帮助企业更好地解决以上问题。
1）管理员可以自行查看系统健康观测，在用户反馈前主动发现系统出现了卡慢，无需被动等待
2）将用户实际体验，以数据形式准确展示出来
详情请参见：场景案例-健康观测
1. 概述
诸如报表加载时间长、系统内存溢出、服务器崩溃等性能问题，影响因素可能有很多，很多时候想要排查也是无从下手。
为了帮助用户在遇到这些性能问题时，可以进行自检调优，现给出性能优化指导方案，可以根据步骤排查工程性能问题，优化系统性能。
单张模板加载慢请按照本文第3节进行优化，其他问题请按照本文第2节进行优化
2. 服务器性能优化
2.1 内存配置检查
根据 运维监控指导手册 中3.4节检查内存配置。
重要提醒：
报表使用内存不只是 Java 堆的内存，报表把日志 IO 打包在堆外内存处理，需要设置堆外内存的上限，以避免 Java 使用过多内存。
设置方法是在内存配置文件后面加上：
-Dfineio.read_mem_limit=2 -Dfineio.write_mem_limit=1 -Dfineio.cache_mem_limit=1 -XX:MaxDirectMemorySize=2g
其中 MaxDirectMemorySize 是 NIO，-Dfineio 是 fineio，设置限制后，两个 IO 能用的最大内存是5G，如果不加限制， IO 可能用到的最大内存是物理内存的一半。
Java堆内存使用建议配置：
1）开启智能释放，操作如下图所示：
2）根据建议设置数据上限，操作如下图所示：
详细介绍可参考：模板限制
2.2 环境配置项检查
参考 运维监控指导手册 中3.4节检查环境配置项，重点检查回收器类型、JDK版本。此处给出一些配置建议：
建议 JVM 使用垃圾回收器类型为 ParallelScavenge
建议使用 JDK8 中 1.8.0_181 及以上版本
2.3 基本维护检查
参考 运维监控指导手册 中第4节检查基本维护指标，此处也补充工程重启操作方法：
Linux：
1）使用命令ps -ef | grep tomcat查询进程 pid ，如果看到有两个进程是正常现象，以 startup.Bootstrap start 结尾的是 Tomcat 的进程，另外一个是宕机处理插件的进程；
2）使用命令kill -9 pid杀掉进程；
3）使用 cd 命令切换到 tomcat/bin 目录 执行./startup.sh（非 root 用户启动，注意执行权限，以及对磁盘的读写权限）
Windows：
关闭 Tomcat 后，任务管理器里找 Java 的进程，如果还有，就手动结束掉。然后在启动 Tomcat。
2.4 其他检查
参考 运维监控指导手册 中3.1、3.2、3.3、3.6节进行检查，包括端口、网络、存储服务、业务配置。
3. 报表性能优化
3.1 使用 FineDataLink 处理数据
报表中复杂的数据处理场景，比如：模板数据集中的复杂 sql 计算、报表单元格间的关联过滤计算，可交给更专业的数据处理工具 FineDataLink 来完成。
| 当前方案 | 新方案 | |
|---|---|---|
| 数据处理过程 | 在 FineReport 中写复杂 SQL 处理数据，再使用 SQL 语句查询后的数据制作模板 示例：
| 1）应用 FDL 数据同步 或 数据转换 功能，将复杂的数据处理、计算过程交由 FDL 实现 示例： 2）FR 报表数据集只需要保留select * from table的方式获取结果指标数据，进而缩短 FR 数据集查询时间，提升报表展示速度 示例： |
| 报表加载示例 | | |
| 客户案例示例 | 某医疗卫生行业的 FineDataLink 合作客户，有张大屏模板查询较慢，需要 60s 时间。该客户后面选择 4 个 SQL 预览时间最久的模板数据集，使用 FineDataLink 的定时任务完成对应数据的获取，并将数据存储至数据中间库内，大屏模板数据集内只使用select * from table的方式获取结果表全部数据，优化后大屏预览只需要 5s | |
FineReport 处理数据时遇到的一些问题 FineDataLink 有对应解决方案，请参见：FineDataLink 如何助力报表开发与应用
点击 FineDataLink产品简介 文档可了解该产品。
3.2 抽数缓存
适合数据量不大，取数频繁，且数据更新时效要求不高的场景，可以把 SQL 查出来的数据存到缓存里，规避重复取数，提高执行效率。
详情参考：抽数缓存介绍
3.3 并行取数
报表默认是计算到的数据，再去执行 SQL 查询，用并行取数，可以在开始的时候，就先把要计算的 SQL 一次执行完毕，可以提高取数时间。
详情参考：数据集并行取数优化插件
该方案不适用的场景：单模板的 SQL 不多；有 SQL 执行复杂，数据库性能不好；有模板的 SQL 实际没有使用。
3.4 新计算引擎
如果模板数据量大，业务场景可以接受分页的展现形式，可以考虑用新计算引擎，新计算引擎通过预编译，后台分页计算的形式，大大提高计算的速度。
方案介绍：新计算引擎介绍
开启方法：开启新计算引擎
3.5 大数据集导出
如果有大数据量导出文件的场景，建议用大数据集导出的功能，默认的导出功能，后台肯定是全量计算，内存使用容易过多。
详情参考：大数据集导出
3.6 模板制作优化
在设计模板时可以使用一些技巧规避可能带来的性能问题：巧用参数注入、优化报表取数、优化报表计算时间、巧用相邻连续分组
