Wakapi项目中过滤查询性能优化实践

背景与问题分析

在Wakapi这个开源的时间追踪项目中，用户反馈在使用特定标签过滤查询编码时间时遇到了严重的性能问题，请求甚至会在完成前超时返回HTTP 502错误。经过深入分析，发现当前实现存在一个关键的性能瓶颈：无论应用何种过滤器，系统都会先获取用户的所有心跳数据（heartbeats），然后在应用层进行过滤计算。

对于拥有大量心跳数据的用户（例如35万条记录），这种处理方式会导致显著的性能下降。特别是在资源受限的环境（如老旧服务器）上运行时，问题更加突出。

技术挑战与解决方案探索

初始思路的局限性

最直观的解决方案似乎是直接在数据库查询中添加过滤条件（如WHERE LABEL='foo'），仅获取相关的心跳数据。然而，这种简单方法存在一个根本性的技术挑战：

Wakapi计算编码时间的逻辑需要考虑心跳之间的时间间隔和超时设置（heartbeatsTimeout）。如果两个标记为"foo"的心跳之间存在其他标签的心跳，且间隔小于超时阈值，这些中间心跳会影响最终的总编码时间计算。

举例说明：

1. t=0s，标签foo
2. t=60s，标签bar
3. t=150s，标签foo

假设heartbeatsTimeout=120s：

• 仅查询foo标签会得到错误的总时间（240s）
• 实际应考虑所有相关心跳，正确结果应为270s

深入技术方案对比

项目维护者曾尝试过多种解决方案：

1. 纯SQL实现方案：早期尝试将计算逻辑完全用SQL实现，但由于需要数据库特定语法（如窗口函数），无法保持跨数据库兼容性。

2. 混合实现方案：为MySQL和PostgreSQL编写特定优化查询，其他数据库回退到应用层计算。虽然可行，但增加了代码复杂性和维护成本。

3. 中间层持久化方案：引入"Duration"实体作为心跳和摘要之间的中间层，预先计算并持久化时间段数据。这种方案可以：

   • 在心跳到达时实时计算
   • 避免每次请求时的批量计算
   • 支持更高效的过滤查询

最终优化方案与效果

项目采用了中间层持久化方案，通过以下技术改进显著提升了性能：

1. 重构Duration计算逻辑，使其能够增量更新
2. 优化数据库查询，减少不必要的数据传输
3. 改进缓存策略，减少重复计算

性能对比测试显示，对于特定条件下的过滤查询（interval=any，project=wakapi）：

• 优化前：12.6秒
• 优化后：1.3秒

性能提升近10倍，有效解决了用户遇到的超时问题。

经验总结与最佳实践

通过这次优化，我们获得了以下宝贵经验：

1. 理解业务逻辑的复杂性：看似简单的过滤查询可能隐藏着复杂的业务规则，必须全面理解所有计算场景。

2. 分层设计的重要性：在心跳原始数据和摘要统计之间引入中间层，可以平衡实时性和性能需求。

3. 性能优化的权衡：在跨数据库兼容性和性能之间需要做出合理权衡，优先保证核心功能的稳定性和正确性。

4. 渐进式优化策略：从最影响用户体验的场景入手，逐步优化关键路径，而非一次性重构整个系统。

这次优化不仅解决了具体的技术问题，也为Wakapi项目未来的性能改进提供了可复用的架构模式和实现经验。