<p>Use Kubernetes and Helm. </p>

<p>I would recommend using the Jenkins Helm chart. It installs with <code>helm install stable/jenkins</code> and automatically scales.</p>

<p><a href="https://github.com/kubernetes/charts/tree/master/stable/jenkins" rel="nofollow noreferrer">https://github.com/kubernetes/charts/tree/master/stable/jenkins</a></p>

CC BY-SA 3.0
2017-04-24T17:39:49.343Z
2018-04-23T13:27:18.127Z
2018-04-23T13:27:18.127Z
David West
<p>I think you should do neither ;) </p>

<p>Well kinda. I think you need more executors, maybe your builds are really resource intensive? I would run at least 4 but we run 6 to 8 depending on jobs. I like to match # of cores to exectors. So you might want to scale up your nodes, I think we run a M4 large for our 4-8 executors.</p>

<p>I also think you should scale-out but you should do so smartly. Jenkins has a plugin to <a href="https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin" rel="nofollow noreferrer">automatically scale-out on AWS</a> depending on what is in the build queue. Basically you tell it how many jobs and how long the wait before it stands up a slave and sends the jobs to the new slave. You can also set the max amount of slaves, the min amount etc.</p>

CC BY-SA 3.0
2018-04-24T14:17:51.100Z
2018-04-24T14:17:51.100Z
Levi
<p>I'd scale out instead of scale up, going for option 3.
We have made a setup where we have all Jenkins agents running on an ECS (custom Docker based Jenkins) with an auto-scaling group. We have all our Jenkins masters communicating to the ECS, thus sharing the workload on the ECS, and no need to recreate the Jenkins master in a scale up exercise.</p>

CC BY-SA 3.0
2017-04-22T18:54:54.723Z
2017-04-22T18:54:54.723Z
Jon Brohauge
<p>There are no <em>fundamental</em> technical issues with running multiple jenkins slaves on the same machine. In fact <a href="https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-RunningMultipleSlavesontheSameMachine" rel="nofollow noreferrer">Running Multiple Slaves on the Same Machine</a> lists several good reasons for doing it:</p>

<blockquote>
  <p>While the correct use of executors largely obviates the need for
  multiple slave instances on the same machine, there are some unique
  use cases to consider:</p>
  
  <ul>
  <li>You want more configurability between the configured nodes. Say you have one node set to be used as much as possible, and the other node
  to be used only when needed.</li>
  <li>You may have multiple Jenkins master installations building different things, and so this configuration would allow you to have
  slaves for more than one master on the same box. That's right, with
  Jenkins you really can serve two masters.</li>
  <li>You may wish to leverage the easiness of starting/stopping/replacing virtual machines, perhaps in conjunction with Jenkins plugins such as
  the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Libvirt+Slaves+Plugin" rel="nofollow noreferrer">Libvirt Slaves Plugin</a>.</li>
  <li>You wish to maximize your hardware investment and utilization, at the same time minimizing operating cost (e.g. utility expenses for
  running idling slaves).</li>
  </ul>
</blockquote>

<p><em>In general</em> scaling out is preferred, primarily because ability to scale up is typically limited by the types/sizes of the available physical resources.</p>

<p>In particular for augmenting build power I'd recommend an analysis of your <strong>actual</strong> build  to determine how it uses the machine resources, which/where its bottlenecks are and what scalability limitations it raises to reveal if scaling up even helps. </p>

<p>For example I encountered cases in which the build time for 2 parallel builds on the same machine was longer than the combined build times of the same 2 builds executed sequentially (non-overlapping) on the same machine. In such case I wouldn't even consider scaling up as it would actually <em>decrease</em> the overall building capacity.</p>

CC BY-SA 3.0
2017-03-09T16:49:35.503Z
2018-03-05T15:27:03.157Z
2018-03-05T15:27:03.157Z
Dan Cornilescu
<p>In my project we have one AWS server running Jenkins Master + 1 Jenkins slave (2 executors)... and we need more<br>
In order to augment our build power we have three options:</p>

<ol>
<li><strong>Scale up</strong>: Make AWS instance bigger and add more executors.</li>
<li><strong>Scale up</strong>: Make AWS instance bigger and add another jenkins slave process.</li>
<li><strong>Scale out</strong>: Create another AWS instance with a jenkins slave and connect it to master</li>
</ol>

<p>We want to do 2. as we are in a big organization and our current Jenkins Master has already access to every place he needs. Option 3. "New server" is complicated as it needs more bureaucratic approvals that will take weeks.</p>

<p>So my questions are:</p>

<ul>
<li><strong>Is there any technical issues in option 2?</strong>. Maybe the executors of each jenkins slave are not aware of the other slave executors?</li>
<li>In general, <strong>what is the best approach to scale Jenkins?</strong> Scaling up or scaling out?</li>
</ul>

CC BY-SA 3.0
2017-03-09T10:40:20.550Z
You'll have a pitfall, changing an instance type could be problematic if you move to a different hardware type, as your volume would have to be backed up and restored in the new instance.
Tensibai
CC BY-SA 3.0
2017-03-09T13:32:02.627Z
Why not number 3? The usual way to send jobs to Jenkins is to master. And based on certain criterias master will send it seamless to appropriate slave
Romeo Ninov
CC BY-SA 3.0
2017-03-09T15:02:12.057Z
FWIW, you need to also analyze your build structure to see how it uses the build machine's resources - scaling up *might* not help - I encountered cases in which the build time for 2 parallel builds on the same machine was longer than the combined build times of the same 2 builds executed sequentially, non-overlapping. In such case #3 would really be the only practical option available.
Dan Cornilescu
CC BY-SA 3.0
2017-03-09T15:53:33.577Z
I agree that #3 is better but I don't have arguments for it or arguements against #1 and #2...
Oscar Foley
CC BY-SA 4.0
2019-05-25T15:54:18.237Z
If you have the opportunity within your environment, I would look to an ephemeral solution. Seeing that you're already in AWS, you could easily bring machines up and down as needed while handling the workload. https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin
casey vega
<jenkins><continuous-integration><capacity-planning>
How to properly scale Jenkins?
Oscar Foley
# How to properly scale Jenkins?

(Asked by: username_0 on 2017-03-09)

In my project we have one AWS server running Jenkins Master + 1 Jenkins slave (2 executors)... and we need more  
In order to augment our build power we have three options:

1. **Scale up**: Make AWS instance bigger and add more executors.
2. **Scale up**: Make AWS instance bigger and add another jenkins slave process.
3. **Scale out**: Create another AWS instance with a jenkins slave and connect it to master

We want to do 2. as we are in a big organization and our current Jenkins Master has already access to every place he needs. Option 3. "New server" is complicated as it needs more bureaucratic approvals that will take weeks.

So my questions are:

* **Is there any technical issues in option 2?**. Maybe the executors of each jenkins slave are not aware of the other slave executors?
* In general, **what is the best approach to scale Jenkins?** Scaling up or scaling out?

**Tags:** jenkins, continuous-integration, capacity-planning

> **Comments:**
> **username_1**: You'll have a pitfall, changing an instance type could be problematic if you move to a different hardware type, as your volume would have to be backed up and restored in the new instance.  
> **username_2**: Why not number 3? The usual way to send jobs to Jenkins is to master. And based on certain criterias master will send it seamless to appropriate slave  
> **username_3**: FWIW, you need to also analyze your build structure to see how it uses the build machine's resources - scaling up *might* not help - I encountered cases in which the build time for 2 parallel builds on the same machine was longer than the combined build times of the same 2 builds executed sequentially, non-overlapping. In such case #3 would really be the only practical option available.  
> **username_0**: I agree that #3 is better but I don't have arguments for it or arguements against #1 and #2...  
> **username_4**: If you have the opportunity within your environment, I would look to an ephemeral solution. Seeing that you're already in AWS, you could easily bring machines up and down as needed while handling the workload. https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin  

---

## 4 answers

### Answer by username_3 on 2017-03-09. Score: 14 | Accepted answer

There are no *fundamental* technical issues with running multiple jenkins slaves on the same machine. In fact [Running Multiple Slaves on the Same Machine](https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-RunningMultipleSlavesontheSameMachine) lists several good reasons for doing it:

> While the correct use of executors largely obviates the need for
> multiple slave instances on the same machine, there are some unique
> use cases to consider:
>
> * You want more configurability between the configured nodes. Say you have one node set to be used as much as possible, and the other node
>   to be used only when needed.
> * You may have multiple Jenkins master installations building different things, and so this configuration would allow you to have
>   slaves for more than one master on the same box. That's right, with
>   Jenkins you really can serve two masters.
> * You may wish to leverage the easiness of starting/stopping/replacing virtual machines, perhaps in conjunction with Jenkins plugins such as
>   the [Libvirt Slaves Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Libvirt+Slaves+Plugin).
> * You wish to maximize your hardware investment and utilization, at the same time minimizing operating cost (e.g. utility expenses for
>   running idling slaves).

*In general* scaling out is preferred, primarily because ability to scale up is typically limited by the types/sizes of the available physical resources.

In particular for augmenting build power I'd recommend an analysis of your **actual** build to determine how it uses the machine resources, which/where its bottlenecks are and what scalability limitations it raises to reveal if scaling up even helps.

For example I encountered cases in which the build time for 2 parallel builds on the same machine was longer than the combined build times of the same 2 builds executed sequentially (non-overlapping) on the same machine. In such case I wouldn't even consider scaling up as it would actually *decrease* the overall building capacity.


---

### Answer by username_5 on 2017-04-24. Score: 7

Use Kubernetes and Helm.

I would recommend using the Jenkins Helm chart. It installs with `helm install stable/jenkins` and automatically scales.

<https://github.com/kubernetes/charts/tree/master/stable/jenkins>


---

### Answer by username_6 on 2018-04-24. Score: 4

I think you should do neither ;)

Well kinda. I think you need more executors, maybe your builds are really resource intensive? I would run at least 4 but we run 6 to 8 depending on jobs. I like to match # of cores to exectors. So you might want to scale up your nodes, I think we run a M4 large for our 4-8 executors.

I also think you should scale-out but you should do so smartly. Jenkins has a plugin to [automatically scale-out on AWS](https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin) depending on what is in the build queue. Basically you tell it how many jobs and how long the wait before it stands up a slave and sends the jobs to the new slave. You can also set the max amount of slaves, the min amount etc.


---

### Answer by username_7 on 2017-04-22. Score: 2

I'd scale out instead of scale up, going for option 3.
We have made a setup where we have all Jenkins agents running on an ECS (custom Docker based Jenkins) with an auto-scaling group. We have all our Jenkins masters communicating to the ECS, thus sharing the workload on the ECS, and no need to recreate the Jenkins master in a scale up exercise.


---

