Differing build queue times with different settings and versions
Spencer Murata (2.3k●11●59●71)
| asked Feb 22 '13, 10:38 a.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Feb 22 '13, 10:57 a.m.
I noticed that there are different queued times for Build Forge agent builds between 3.0.1.x and 4.0.1, where 3.0.1.x is queued for less time than 4.0.1. Also I noticed that if I specify a build engine, rather than using Any Build Engine, the build is queued for less time. What causes this?
|
Accepted answer
Starting with the specified engine vs any build engine, the difference in queue time is caused by the "any build engine" option testing all supported engines before selecting a candidate engine, whereas specifying an engine will just check that one engine. Depending on the latency times for the supported engines and how many supported engines there are, this can cause an increased queue time.
For the queue time differences between 3.0.1.x and 4.0.x, there was a code change between the two versions. Previously we would check engine availability only if there was a queued build against that engine, so the loop responsible for picking up builds would only have to test those build engines that had a potential build request. However in 4.0.x, there is a change that will cause the engines to always test the connectivity as often as the threshold settings for the engine specified, which is a setting that was ignored previously. The extra checks though for the threshold, especially with the default time of three minutes can add overhead to the build request loop, which leads to longer queue times. To return to the previous 3.0.1.x behavior, disable the threshold checking, and the queue time should fall to the previous levels.
~Spencer
Spencer Murata selected this answer as the correct answer
Comments
Geoffrey Clemm
commented Feb 23 '13, 12:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
What is the benefit of the 4.0.x behavior over the 3.0.2.x behavior?
As of 4.0.x we are actually checking ALL BF agent engine availablities, not just those that have a request against them. Previously it would be possible for a engine to be down for a long time, and it would only be reflected in the UI when a build was put against it. Essentially we now honor the threshold settings on the BF agent engines properly, instead of only updating it when we happen to look at them. ~Spencer |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.