How many Build Forge agents to run on a (compile) server - how often to update the manifest?
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! |
2 answers
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.
Comments 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.
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.
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.
|
|
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
|
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.