詹金斯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響應調整

回答

相關問題