A Jenkins controller that is shared between several teams in an organization might end up with a large number of jobs and significant configuration complexity.
As a Jenkins administrator, you might find that your systems suffer from performance issues, overly complex configuration, and difficult maintenance requirements. It is also possible that teams in your organization are impacted by changes performed by other teams. For this reason, CloudBees recommends one controller per team (which is now very feasible using Kubernetes clusters) instead of a single controller that is shared among multiple teams. Our customers who use one controller per team have reported a high degree of success with this configuration.
The maximum number of jobs on a controller depends on many variables. One of the main bottlenecks occurs through improper use of Pipelines.
Pipelines should always execute code on the agents. However, your developers might be using the Pipelines in a way where Groovy code is actually executing on the controller. If that is the case, your developers are introducing "programs" inside the controller, therefore the performance of the instance also depends on these Pipelines your developers are introducing in Jenkins.
Some other variables that might have an impact in determining how well your controller scales vertically include:
-
The number of plugins used
-
The average number of items in the build queue
-
REST API calls
-
File system performance
-
The number of simultaneous jobs being run
-
Complex authorization security rules
The following sections explain how to split a controller in both CloudBees CI on traditional platforms and CloudBees CI on modern cloud platforms.
Refer to Kubernetes on-premise and OpenShift - Cluster sizing and scaling for more information about controller sizing guidelines.