1. 概述
诸如报表加载时间长、系统内存溢出、服务器崩溃等性能问题，影响因素可能有很多，很多时候想要排查也是无从下手。
为了帮助用户在遇到这些性能问题时，可以进行自检调优，现给出性能优化指导方案，可以根据步骤排查工程性能问题，优化系统性能。
单张模板加载慢请按照本文第3节进行优化，其他问题请按照本文第2节进行优化
2. 服务器性能优化
2.1 重启操作不当
报表启动前需要确保之前的服务没有残留进程，否则将不能正确启动，且内存容易使用过量。此处给出建议的重启方式，以 Tomcat 为例：
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.2 内存分配不合理
FineReport10.0 堆内存使用，把处理日志的功能独立出来单独用一部分 IO 的内存，所以不仅要分配堆内存，还要分配 IO 内存。
如果不做限制，堆外内存容易占用过多，进而导致对整个系统的内存使用过多，严重会造成进程消失。
具体看，堆外内存分两部分 fineio 和 nio，由于小版本 fineio 做过调整， 配置不一样，可以根据目前工程 JAR 包日期结合下表做一些对照：
| JAR包日期 | nio | fineio | 完整建议配置写法 |
|---|---|---|---|
| 2020-01-15之前 | -XX:MaxDirectMemorySize=2g | 无 | -XX:MaxDirectMemorySize=2g |
| 2020-01-15 ~ 2020-04-26 | -XX:MaxDirectMemorySize=2g | -Dfineio.direct_mem_limit=4 | -XX:MaxDirectMemorySize=2g -Dfineio.direct_mem_limit=4 |
| 2020-04-26之后 | -XX:MaxDirectMemorySize=2g | -Dfineio.read_mem_limit=2 -Dfineio.write_mem_limit=1 -Dfineio.cache_mem_limit=1 | -XX:MaxDirectMemorySize=2g -Dfineio.read_mem_limit=2 -Dfineio.write_mem_limit=1 -Dfineio.cache_mem_limit=1 |
表中堆外内存的设置写法，添加到之前内存配置后面，详情可参考：Tomcat修改内存
合理的原则是，IO 内存加上最大堆内存，不要超过所在机器物理内存的90%，
比如16g的物理机器，只跑报表推荐的内存配置是：
-Xmx8192M -XX:MaxDirectMemorySize=2g -Dfineio.read_mem_limit=2 -Dfineio.write_mem_limit=1 -Dfineio.cache_mem_limit=1
32g的物理机器，只跑报表工程建议的内存是：
-Xmx16384M -XX:MaxDirectMemorySize=2g -Dfineio.read_mem_limit=2 -Dfineio.write_mem_limit=1 -Dfineio.cache_mem_limit=1
注：32g的物理内存不建议配置 Xmx24g 及以上，因为 24+2+3=29，比较危险。
如果您的 JAR 包日期在 2021-03-08 之后，也可以通过系统检查插件，检查内存分配以及后续的系统配置。
2.3 内存回收设置
报表建议的内存回收方式是 JDK1.8 默认的回收器 ParallelScavenge，堆内存老年代和新生带的比例建议是默认值，不要调整。
报表工程建议开启智能释放的功能，如下图所示：
如果您的 JAR 包日期在 2021-03-08 之后，也可以通过系统检查插件，检查内存分配以及后续的系统配置。
2.4 短时间内存使用量过大
短时间内存使用过量，容易造成宕机，为了规避宕机，可以给报表设置数据查询的上限，如果数据量超过设置，可以及时中止计算，规避宕机发生。
数据量上限的建议，可以参考 模板限制增强插件 的建议值。
2.5 报表工程数据库FineDB设置
报表工程数据库 FineDB 是存储报表项目用户数据的数据库，需要迁移到外接数据库，且不能多个报表工程共用一个数据库（集群除外）。
2.6 JDK版本低
建议使用 JDK8 中 1.8.0_181 及以上版本
2.7 其他检查
可以参考 FineReport11.0 的 运维监控指导手册，虽然10.0的检查功能和11.0的不一样，但是检查的内容项是一样的，可以参考。
3. 报表性能优化
3.1 抽数缓存
适合数据量不大，取数频繁，且数据更新时效要求不高的场景，可以把 SQL 查出来的数据存到缓存里，规避重复取数，提高执行效率。
详情参考：抽数缓存介绍
3.2 并行取数
报表默认是计算到的数据，再去执行 SQL 查询，用并行取数，可以在开始的时候，就先把要计算的 SQL 一次执行完毕，可以提高取数时间。
详情参考 性能优化插件 下的并行取数功能。
该方案不适用的场景：单模板的 SQL 不多；有 SQL 执行复杂，数据库性能不好；有模板的 SQL 实际没有使用。
3.3 新计算引擎
如果模板数据量大，业务场景可以接受分页的展现形式，可以考虑用新计算引擎，新计算引擎通过预编译，后台分页计算的形式，大大提高计算的速度。
详情参考：新计算引擎插件介绍
3.4 大数据集导出
如果有大数据量导出文件的场景，建议用大数据集导出的功能，默认的导出功能，后台肯定是全量计算，内存使用容易过多。
详情参考：大数据集导出