MeterSphere定时任务清理报告的性能优化实践

背景介绍

MeterSphere作为一款开源的一站式测试平台，在日常使用中会积累大量的测试报告数据。随着系统运行时间的增长，这些报告数据会占用大量存储空间，因此平台提供了定时清理功能来维护系统性能。然而，在实际使用中发现，当清理大量场景报告时，系统会出现明显的性能问题。

问题分析

在MeterSphere v2.10.23版本中，定时清理功能存在以下两个主要性能问题：

1. 批量删除处理单元过大：当前代码中设置的handleCount为2000，这个值对于场景报告来说过大。因为每个报告(report)下可能关联多个测试场景，而每个场景中又包含多个步骤，导致实际删除的数据量会呈倍数增长（2000×n），造成删除操作耗时过长。

2. 删除逻辑实现不够高效：当前的批量删除实现方式可以通过更简洁的分片处理来优化。使用Apache Commons Collections库中的ListUtils.partition方法可以更优雅地实现列表分片处理。

技术解决方案

批量删除优化方案

针对第一个问题，建议优化ApiScenarioReportService中的deleteAPIReportBatch方法：

1. 适当减小handleCount的值，根据实际测试数据评估，建议调整为500或更小值
2. 采用更智能的分批处理策略，考虑报告关联数据的复杂度动态调整批次大小

代码重构方案

针对第二个问题，可以重构batchDeleteReportResource方法，使用ListUtils.partition实现更简洁的分批处理：

public void batchDeleteReportResource(List<String> ids) {
    if (CollectionUtils.isEmpty(ids)) {
        return;
    }
    
    ListUtils.partition(ids, BATCH_SIZE).forEach(batch -> {
        apiScenarioReportResultMapper.deleteByReportIds(batch);
        extApiScenarioReportMapper.deleteByIds(batch);
    });
}

异步处理机制

由于删除操作耗时过长会导致以下问题：

• Kafka消费者因两次消息间隔时间过长被踢出消费组
• 触发消费者重新加入和rebalance过程
• 可能导致消息丢失

建议将删除操作改为异步执行，示例代码结构：

@Async
public void asyncDeleteReports(List<String> ids) {
    // 执行实际的删除逻辑
    batchDeleteReportResource(ids);
}

实施建议

1. 性能测试：在实施优化前，应对不同批次大小进行性能测试，找到最优的handleCount值
2. 监控机制：添加删除操作的执行时间监控，便于后续持续优化
3. 事务管理：异步删除时需注意事务边界，确保数据一致性
4. 错误处理：完善异步任务的错误处理和重试机制

预期效果

通过上述优化措施，预期可以获得以下改进：

1. 显著减少单次删除操作的执行时间
2. 降低对Kafka消费者组稳定性的影响
3. 提高系统整体响应速度
4. 减少因长时间操作导致的资源锁定

总结

定时任务清理功能是测试平台维护的重要组成部分，其性能直接影响系统稳定性。通过对MeterSphere报告清理机制的优化，不仅可以解决当前版本中的性能问题，也为后续处理大规模数据积累提供了可扩展的解决方案。在实际实施中，建议根据具体业务场景和数据规模进行参数调优，以达到最佳性能表现。