Jazz Build 'Fetching files' activity, performance question
Perhaps I'm just impatient, but I'd like a sanity-check on the performance of the build's 'Fetching files' activity. I am on RTC3 and have a setup where I run builds continuously so that any single build execution accepts a relatively small # of changesets. On a relatively small workspace, I see the 'Fetching files' activity taking about 25 seconds. On a relatively large workspace, I see the 'Fetching files' activity taking about 7 minutes.
Given that the workspace is already loaded locally and the builds are continuously run (i.e. very few differences between local workspace and server), I am wondering if this aspect of the build should really be taking that long and whether or not 'Fetching files' should [seem to] be proportional to the overall size of the workspace regardless of the # of changes being accepted. Thanks, Eric |
2 answers
Ralph Schoon (63.1k●3●36●46)
| answered Nov 30 '12, 4:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi, one thing I have learned in the past is that the CCM application does some caching, so the fetch times should decrease if you fetch the data into the same location. However, the fetch has to still check all files on disk against the files in the repository. For example, I deleted some required files in the fetch destination and the SCM system detected the missing files and loaded them. So it not just loads the changes, but checks all files. Subsequent builds (if keeping the fetch destination) are shorter than the first full fetch and it averages in a shorter time frame.
In general, build creates a considerable load on the server and the network. You can reduce the load using a Squid caching proxy between the build engine on the build site and the CCM server. Comments Hi, I have a similar problem. Today the first build takes 3 min 33 sec and the second build for the same changeset takes 1 min 28 sec. I see this difference every day between the first build and all the following. As this is only a little change set this is not a problem but I have seen Build which take about 20 min and the following same build takes only 5 min. Build Engine and server are on system-i V6R1 and we have installed RTC 301 Thanks for information Andreas
And the third build takes 20 sec. The first run against our testenvironment and the last against production.
|
|
Ralph Schoon (63.1k●3●36●46)
| answered Nov 30 '12, 4:39 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To reduce build times in the morning, schedule a build for before start of business. The caches expire and you can enforce rebuilding them with a scheduled build.
Comments Must this build include changesets or is it possible to start a build where only the compile of a dummypgm will run? I don't know. I believe It needs to fetch data, so you would have to uncheck the "Build Only if there are changes accepted" checkbox. but I am actually not sure. You can run some tests. You could have a special build definition for that if you require to uncheck the checkbox.
Thanks for information, I will test this next week and let you know if this is the right way. |
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.