Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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


0 votes



2 answers

Permanent link
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.


0 votes

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.


Permanent link
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.

0 votes

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

Register or log in to post 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Nov 29 '12, 12:20 p.m.

Question was seen: 4,805 times

Last updated: Nov 30 '12, 5:28 a.m.

Confirmation Cancel Confirm