-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add round-robin priority type #3
Comments
Hello! |
Good day, @Funbit! Sorry for low activity, have some things happening in my life :) Would like to know your opinion on the implementation details. On SO post you mentioned "
Random is quite easy to implement, I will just use built in random functionality.
Please let me know if this sounds reasonable or you have some other ideas. |
Hi! Glad that you're okay :) |
Yep, random priority is super easy to implement indeed... RR is tougher but still possible :) Can you please share your use-case for such agent priority? |
The use case is simple, we're using AWS t2.* instance types for TC agents. Such instances have a given CPU quota (i.e. if an instance consumes 100% CPU for a long time it will be slowed down by AWS). Since we have 3 agents and some of our project tests consumes 100% CPU for 10-20 minutes, it's always good to distribute the load among all instances, so some of them can rest. |
Well, in this case round-robin would not work as expected for your case. Let's say you have 5 builds: Triggering sequentially all builds using proposed algorithm would simply use the same agent:
Because RR is going to explore only current build's history, ignoring others. So running Originally described RR could be also useful, for example in order to support working copy on all agents up to date. Your case is slightly different, as we have to equally distribute load by agents, not by builds. To do that, we have to get all available agents, get history for each one and calculate priority depending on this information. But here is corner case with two agents: |
Well, maybe I was too rushed indeed :) However, the proposed RR algorithm should satisfy our case (i.e. do RR based on projects), since in our environment we have a single large project that takes 99% of time/cpu and several small ones, used only for deployment-like actions which don't consume time/cpu much. Thus, having evenly distributed agent load for each project should work fine. |
@Funbit, I've released v.1.0.2 plugin version with random agent distibution. Please, have a look and tell me how it works. I'm still thinking about how to distribute load between agent more wisely. |
So, if we have a long running
So we would have running history like this: This example shows, that we have to take into account not only the order, by which agents were picked up for running builds, but also the time, which they were busy. @Funbit, does this example is close to your situation? Or maybe you have some other criteria to take into account? |
Thank you for the update! I've installed 1.0.2 version, will try to see how it works (tried 2 times, got 2 different agents :) So I suppose it works fine!). |
@grundic, loading history can dramatically decrease performance. I think it would be better to use agent's "idle" time. So, less loaded agent will be used all-the-time. |
@Jimilian, that's a brilliant idea! Indeed, relying on build history is a big performance hit, though ByBuildStatus priority is already using it (though it lets the user to limit the history exploration). There is a getIdleTime method for the SBuildAgent, which returns exactly what you described. I've made some tests and here how it works: this method returns the idle time of an agent since the last finished build. So it doesn't take into account any intermediate outages and resets after any build by the agent is finished. @Funbit, can you please tell whether this solution would work for you? I have very representative example of the agent distribution for a single build: As you can see, agents always kept in order of Default Agent | aaa111 | zzz999 |
Hmm, what if I register a new agent after using existing ones for some time? Wouldn't it affect the priority distribution? (new agent would have to be prioritized until its idle time becomes greater than existing agents? Or am I wrong?) |
From Java documentation:
-Edit- |
Thank you! Will try the new idle based priority within this week and get back with the results. |
From the comment on the SO:
The text was updated successfully, but these errors were encountered: