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

How many Build Forge agents to run on a (compile) server - how often to update the manifest?

Questions
Tags
Users
Badges
Martina Riedel
(203●2●33●41) Mar 24 '14, 8:28 p.m.
BF 7.1.2

We have 1 (soon to be 2) Linux build servers. We have 3 different kinds of builds that currently use 3 different logins and each has their own agent configured with a different port and magic_login in the config file.

Overall we expect the volume of builds to increase and I am looking for the configuration with the best throughput.

Does it make sense to maintain 3 logins 3 agents etc, or will I get the same or better performance with 1 login for all 3 kind of builds and 1 agent using 1 port (or 1 login using more than 1 agent and port).

With the 2nd server coming online, I would like to have the BF selector select either server depending on current load, i.e. I need to run a manifest update regularly. Our builds run between 10 minutes and 2hrs.
Any advice on how often to refresh the manifest? Every 2 minutes? every 15 minutes?

Advice and opinions welcome!

0 votes

2 answers
4,748 views
0 votes

2 answers

Permanent link
Ryan Ruscett
(1.0k●4●13) Mar 25 '14, 9:27 a.m.
 Hello,

1. Here is a link that can help you determine choosing one server over another based on load.

2. There is also a way to take a collector and create a "set value" create a variable say "load" and set that variable to 1. On another collector do the same but set variable to 2, 3, etc. This puts inside the collectors a varaible 1, 2, 3, 4 represented in the manifest as not required.  Then iniside the selector you can make a value for 1. Set that value to not required. The builds will then run in order of least busy machine. 

3. Remember, refreshing the manifest is not really important. I would advise to leave it at the default. You can use the Queue Manifest Refresh. to refresh the variables by interval, but unless the manifest is changing frequently, there really isn't a reason to refresh ever 2 minutes or even every 15. Think of it like this. If you had say 300 agents with manifest refreshes happening every 2 or 5 minutes. That would be much more expensive than every 30 minutes. If you only have 10 or so and you want to refresh every 2 minutes you can and it may not have an effect. But determining what is best would depend on to many circumstances. I would just try it out at 2 if you want. Then at 5 and then again at 10. See what works.

4. There wont be any performance gain by using 1 login for 3 agents vs 3 logins for 3 agents. I have seen 3 agents with different ID's and 3 with the same. It is less maintenance if the id's change often you have to change them but with magic logon it's no so important. 

5. throughput is a tough one. If the entire build runs on one or two build servers. It depends on what it's running. One job could be much more intense than another. You could have three jobs on a machine. Once each job starts they just run on the box. If one job or job step is 10 times more expensive than another. It could bog the system down. Which may require another build server or a way of splitting up the steps on different machines in a way that makes sense for what you are doing. 

Hope this helps.


0 votes

Comments
Martina Riedel
Mar 25 '14, 12:34 p.m.

Since I want to start builds depending on how busy a server is, the selector needs to have up-to-date data, dynamic information. Selection Process is a very interesting read, but it doesn't go into how frequently to run the refresh.
So I was wondering whether anybody has practical experience and is willing to say "every x minutes has worked for me".

The other question I still have: is there a performance gain by using 3 agents vs. 1 agent?

Ryan Ruscett
Mar 25 '14, 3:31 p.m.

Each agent has a max jobs. Using 1 agent would cause you to have to increase this number. The more jobs a single agent has the less performance you would get. Now, the threshold for this performance decrease is subject to what the agent or jobs are doing. Having 3 agents would allow you to spread the workload out and thus gain better performance. But if you have 5 jobs on one agent. It's not such a big deal, but for scalability there can be a benefit in performance to use three. 


If you use the collector/selector method. You don't need to refresh the manifest ever. This method will run jobs on the least busy server without the need to do a refresh.  

Martina Riedel
Mar 26 '14, 11:53 a.m.

I don't agree with your statement of "If you use the collector/selector method. You don't need to refresh the manifest ever". See chapter 5.1 of Selection process. here is a quote: Some built-in variables, such as MEM_FREE, lose their efficacy if they are not updated frequently.
I plan to use CPU_LOAD (there are several options) and  the same thing applies.


Permanent link
Ryan Ruscett
(1.0k●4●13) Mar 26 '14, 6:05 p.m.
 Ok, so if you want to figure out how often to refresh the manifest you need to think about a few things.

1. How often are jobs kicked off?.Is there pattern? If you kick jobs off 10 minutes apart. It would be safe to say you can refresh every 8 minutes. If jobs are kicked off at the same time, perhaps you need to schedule the jobs to not be kicked off at the same time. If it's every 5 minutes, refresh the manifest ever 4 minutes. 

2. Number of agents? You don't have very many. So increasing the frequency of the manifest refresh is going to fine. If you had upwards of 200 agents. Then you would be in a whole different realm and most likely would not be able to do it every 2 or 5 minutes. 

3. What kind of processing power do the jobs commit? Everything the agent does it sent back to BF and written to the database. If you are doing a step that requires having a lot of open files and a lot of output for long periods of time. You may need to  

0 votes

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.

Ask a question
Guidelines
FAQ
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
× 12,026

Question asked: Mar 24 '14, 8:28 p.m.

Question was seen: 4,748 times

Last updated: Mar 26 '14, 6:05 p.m.

Confirmation Cancel Confirm