詹金斯API响应调整

我们已经建立在詹金斯的顶部的仪表盘，使用户能够看到相关的项目只工作，也触发构建。 UI是使用reactJS构建的，后端是JAVA REST WebServices。詹金斯API响应调整

WebService的调用詹金斯API来获取工作信息和数据，以JSON转换喂养的UI。目前我们在仪表板上有大约200个工作。 Jenkins API需要花费大约2分钟来回复细节。

詹金斯在Linux机器上

OracleLinux 6 x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz/39.25 GB

詹金斯版本上运行 - 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]]]

API被称为200次，200个职位获取的细节每份工作。

就如何加快API响应任何意见。

我认为增加RAM在Linux中和调整JVM OPTS。同时将Jenkins升级到最新的LTS。

来源

2017-02-10 Upen

请问您的工作有许多建立？我知道詹金斯团队一直与建立的延迟加载，不知道哪个版本有这些改进虽然。例如。只要你加载工作，它会加载所有的版本。在较新的版本中，它加载了呈现渲染页面/查询所需的那些。而且，由于在较旧的版本中（使用延迟加载），树查询中的'build [result]'部分可能会更加危险，这将强制作业加载所有构建。原因是没有进行分页，例如，在以后的版本中，你必须指定要返回的版本的范围，默认值是20我认为。 –

我们保留了每项工作30个版本的历史。我只是担心升级Jenkins核心，因为所有的插件可能不兼容。我们正在使用几个插件来使事情发挥作用。 – Upen

好吧，这不是懒惰的加载，30个构建并不多。对于拥有超过1000个版本的工作来说，这只是一个问题。 –

唾手可得：

运行要求在平行，即，不是一个接一个。
如果这样做，并且如果使用标准jetty container，请尝试使用--handlerCountMax选项（缺省值为40）增加工作进程数。

最后，你应该尝试避免执行200所个人要求。根据您的设置，单独安全检查每个请求可能会导致大量开销。

因此，最干净的解决方案将是收集所有你从一个单一的Groovy脚本需要主服务器上的数据（你可以做到这一点通过REST也）：

这减少的数量要求1
，它允许进一步优化，有可能规避上述

来源

2017-02-10 09:53:56

作为一个Java人，我会尝试去除for循环的200个奇怪的电话，并使用CountdownLatch一次性完成。会及时向大家发布。谢谢。 – Upen

我能够将改变的速度从2分钟提高到几秒。 – Upen

感谢您的反馈。这是一个体面的加速：） –

在乔恩·S的评论中提到的问题，因为它似乎像你不打你的任何延迟加载问题r服务器（因为每个作业只有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而不是我们使用詹金斯API，我们可以在一个请求获取所有作业的数据。

来源

2017-02-10 19:34:20

尼斯：）我不知道你可以在一个请求中得到几个工作的结果。 –

詹金斯API响应调整

回答

相关问题