Details
-
Bug
-
Status: Reopened (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
It takes about 20 sec to display any part of the test report when the json file is big enough and there are lots of previous builds.
Attachments
Activity
Anatoly Bubenkov
added a comment - thanks!
and sorry for annoying me Comment from reporter:
"This only happens if there is a large (100+) build history"
This may indicating a recursive load issue - re-opened to investigate.
Vitaliy Skrypnyk
added a comment - I can share a result of our investigation.
The poor performance of Cucumber Test Result Plugin caused by the logic of displaying test results.
Each time when users are visiting Cucumber Test Result page, Cucumber plugin loads previous build results (for calculating age of failed tests).
In case if current build is success plugin load only one previous result, but in case if a build is failed Cucumber plugin will load previous recursively for calculating a Scenario fail age.
This behavior has issues:
1. Method getResult() is synchronized (This mean that only one user can load report for one job).
2. Cucumber plugin is trying to cache test result in WeakReference class field.
3. Calculating of fail age has not optimized algorithm. Cucumber plugin calculates fail age separately for each scenario. That's mean that for 10 failed scenarios in one build, the plugin will try to open (or read from a cached field) the XML results 10 times.
You can see here screenshot with visual VM. When I tried to open a report with 10 failed scenarios in a row Cucumber Plugin is used ~200mb and ~20% of CPU for GC. (Totally we have 868 scenarios)
Vitaliy Skrypnyk
added a comment - I can share a result of our investigation.
The poor performance of Cucumber Test Result Plugin caused by the logic of displaying test results.
Each time when users are visiting Cucumber Test Result page, Cucumber plugin loads previous build results (for calculating age of failed tests).
In case if current build is success plugin load only one previous result, but in case if a build is failed Cucumber plugin will load previous recursively for calculating a Scenario fail age.
This behavior has issues:
1. Method getResult() is synchronized (This mean that only one user can load report for one job).
2. Cucumber plugin is trying to cache test result in WeakReference class field.
3. Calculating of fail age has not optimized algorithm. Cucumber plugin calculates fail age separately for each scenario. That's mean that for 10 failed scenarios in one build, the plugin will try to open (or read from a cached field) the XML results 10 times.
You can see here screenshot with visual VM. When I tried to open a report with 10 failed scenarios in a row Cucumber Plugin is used ~200mb and ~20% of CPU for GC. (Totally we have 868 scenarios) vitaliy_skrypnyk to be clear you are 100% correct and this is by design. There is no guarantee that previous builds have finished when the later build completes. This is the same in the junit plugin.
The slow behavior is due to Memory pressure - if you had more memory available then the prior results would be in memory and would not need to be loaded and parsed - although there is potential that some thing could be improved in this area.
> Cucumber plugin calculates fail age separately for each scenario
this is still required as you do not need to view all scenarios - they can be viewed individually, so calculating this for all scenarios when you are viewing a single scenario will be equally sub-optimal.
Will. Attempt to reproduce