如何在Quarkus环境下实现OptaPlanner应用的高级基准测试

基础依赖适配 #

• 无需照搬传统OptaPlanner独立示例的基准测试栈，直接复用Quarkus OptaPlanner扩展的统一版本管控能力，仅需追加基准测试核心依赖即可，版本由Quarkus平台BOM自动对齐，不存在版本冲突风险：

  <dependency>
    <groupId>org.optaplanner</groupId>
    <artifactId>optaplanner-benchmark</artifactId>
  </dependency>
  

• 基础配置无额外复杂要求，仅需在application.properties中追加两项适配配置：
  • 固定求解器线程数配额，避免自动线程池伸缩导致测试结果偏差：quarkus.optaplanner.solver.thread-pool-size=YOUR_FIXED_THREAD_COUNT
  • 关闭基准测试模块的多语言序列化兼容逻辑，规避原生编译模式下的类加载异常：quarkus.optaplanner.benchmark.enable-polyglot=false

JSON格式业务数据集的加载适配 #

• 针对JSON存储的业务输入数据，完全绕开传统示例的XML数据集加载逻辑，自定义实现基准测试输入加载逻辑：
  • 实现BenchmarkInputProvider接口，复用Quarkus内置的Jackson序列化能力，从指定资源路径读取JSON格式的业务数据集，直接反序列化为对应规划问题的Solution实例，无需编写额外的数据集格式转换脚本。
  • 多测试场景数据集可按业务场景命名，统一存储到src/main/resources/benchmark/datasets/路径下，加载器自动遍历识别不同规模、不同业务复杂度的测试样本。
• 加载逻辑需做一致性校验：反序列化完成后不对Solution实例做任何字段修改，保证所有求解器配置对比时的输入数据完全一致，避免基础数据偏差导致的得分对比失真。

多求解器配置对比的编排逻辑 #

• 放弃传统示例中独立XML配置文件定义基准测试规则的模式，适配Quarkus的CDI运行上下文，直接在代码层完成求解器配置矩阵的构建：
  • 针对需要对比的参数维度（包括不同局部搜索策略、终止时间阈值、移动选择器配置、元启发式算法类型等），逐一生成独立的SolverConfig实例，纳入基准测试的配置对比组。
  • 基准测试触发逻辑完全嵌入Quarkus应用生命周期，无需编写独立的Java SE main方法：可通过@QuarkusMain定义命令行入口，或绑定到REST接口，在应用启动后触发基准测试流程，全程复用CDI容器中已经初始化的约束流、求解器相关Bean，避免重复初始化带来的资源浪费。

基准测试执行与结果输出 #

• 运行流程完全适配Quarkus的常规构建部署链路，无特殊启动要求：
  • 本地开发环境可通过quarkus dev命令直接触发内置的基准测试入口；生产环境验证可直接使用打包后的可执行Jar包或原生二进制文件运行基准测试流程。
  • 结果输出复用OptaPlanner内置的HTML报告能力，基准测试执行完成后自动生成结构化对比报告，内容覆盖每个求解器配置在不同数据集上的最终得分、求解耗时、最优解稳定性、与理论最优值的间隙，无需自行开发结果统计逻辑。
  • 可自定义报告存储路径，将生成的对比报告输出到应用部署目录下的benchmark-reports/文件夹，方便后续版本迭代时的配置效果追溯。

常见适配问题规避 #

• 禁止直接复制传统独立OptaPlanner示例的基准测试代码：传统示例运行在独立Java SE环境，无CDI上下文支持，直接迁移会出现约束流加载失败、规划实体类注入异常的问题。
• 基准测试运行期间需暂停应用的其他非必要资源消费，关闭自动扩缩容、异步任务调度等额外逻辑，保证测试全程的CPU、内存资源独占，避免测试结果波动。
• 测试运行前需对所有数据集做基准得分校验，避免因为JSON反序列化漏字段导致的问题域不完整，出现不同配置得分的无效对比。

内容的提问来源于stack exchange，提问作者Andrej Rus