我们在 Jenkins 之上构建了一个仪表板，使用户只能查看与项目相关的作业并触发构建。UI是使用reactJS构建的，后端是JAVA REST WebServices。
WebService 调用 Jenkins API 来获取作业信息，并将数据转换为 JSON 以馈送 UI。目前，我们在仪表板上有大约 200 个工作岗位。Jenkins API 大约需要 2 分钟才能响应详细信息。
Jenkins 运行在 Linux 机器上
OracleLinux 6 x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz / 39.25 GB
Jenkins 版本 - 1.564，具有 16 个执行程序和 2000 多个作业
Sample API Call - http://jenkins:8080/job/jobName/api/json?tree=displayName,builds[result],lastBuild[estimatedDuration,result,duration,number,timestamp,actions[causes[userName]]]
对于 200 个作业，API 被调用 200 次，以获取每个作业的详细信息。
有关如何加快 API 响应的任何建议。
我考虑在 linux 盒子上增加 RAM 并调整 JVM OPTS。还将 Jenkins 升级到最新的 LTS。
唾手可得的果实：
- 并行运行请求，即不一个接一个地运行。
- 如果这样做并且使用标准
jetty容器，请尝试使用--handlerCountMax选项增加工作进程数(默认值为 40(。
最终，您应该尽量避免执行 200 个单独的请求。 根据您的设置，仅对每个请求进行安全检查就可能导致大量开销。
因此，最干净的解决方案是从主服务器上的单个 Groovy 脚本收集所需的所有数据(您也可以通过 REST 执行此操作(：
- 这会将请求数减少到 1
- 它允许进一步优化，可能规避上面 Jon S 评论中提到的问题
由于您似乎没有在服务器上遇到任何延迟加载问题(因为每个作业只有 60 个构建(，这些问题可能与 Alex O 建议的开销有关。此外，Alex O's建议在一个请求中完成所有操作。这可以通过以下请求完成：
http://jenkins:8080/api/json?tree=jobs[displayName,builds[result],lastBuild[estimatedDuration,result,duration,number,timestamp,actions[causes[userName]]]]
我们不依赖作业 API，而是使用 jenkins API，我们可以在单个请求中获取所有作业的数据。