Woodpecker CI 新仓库列表引发的请求速率限制问题分析

在 Woodpecker CI 的最新版本中，开发团队发现了一个与仓库列表页面相关的性能问题。这个问题会导致系统向服务端发送过多请求，进而触发速率限制机制，影响用户体验。

问题现象

当用户在 Woodpecker CI 的仓库列表页面查看已启用的仓库时，系统会为每个仓库单独发送请求获取最新的流水线信息。测试发现，即使只有7个仓库，系统也会发送14个请求到流水线端点，这明显存在请求翻倍的问题。

更严重的是，当仓库数量较多时（例如10个或更多），这种设计会快速消耗服务器的连接资源，最终触发速率限制机制，返回"max connections reached"的错误提示。

技术分析

深入分析这个问题，我们可以发现几个关键的技术点：

1. 请求翻倍问题：前端代码可能存在逻辑缺陷，导致对同一仓库的流水线信息请求被发送两次。这种重复请求不仅浪费带宽，还增加了服务器负担。

2. 无分页设计：当前仓库列表没有实现分页功能，这意味着用户如果有大量仓库，前端会一次性请求所有仓库的信息及其流水线状态，这对服务器性能是极大的挑战。

3. API设计不足：目前的API设计采用为每个仓库单独请求流水线信息的方式，而不是批量获取，这在仓库数量多时会产生大量HTTP请求。

优化建议

针对上述问题，我们提出以下优化方案：

1. 批量请求优化：建议修改API设计，支持通过单个请求获取多个仓库的流水线信息。例如，可以使用类似pipelines/last?repo_ids=[1,2,3,4,5]的批量查询接口。

2. 数据聚合：可以考虑在返回仓库列表时，直接将每个仓库的最新流水线信息包含在响应中，减少额外的API调用。

3. 请求去重：修复前端代码，确保每个仓库的流水线信息只请求一次，消除当前的重复请求问题。

4. 分页实现：为仓库列表添加分页功能，合理控制每页显示的仓库数量（如10个），避免一次性加载过多数据。

系统影响

这个问题在特定配置下尤为明显。测试环境中使用了Traefik作为反向代理，配置了最大并发连接数为10的限制。当请求超过这个限制时，Traefik会返回HTTP 429状态码和"max connections reached"的错误信息。

虽然这个问题在连接数限制较高的生产环境中可能不会立即显现，但大量不必要的请求仍然会影响系统性能和用户体验，特别是在仓库数量较多的情况下。

总结

Woodpecker CI的仓库列表性能问题是一个典型的前后端协作优化案例。通过改进API设计、优化前端请求逻辑和实现合理的数据分页，可以显著提升系统性能和用户体验。开发团队已经注意到这个问题，并计划在后续版本中进行修复和优化。