Performance tuning in Jenkins - Commands & Configuration

Introduction

Jenkins can slow down when many jobs run or when resources are limited. Performance tuning helps Jenkins run faster and handle more work smoothly.

When Jenkins jobs take too long to start or finish

When the Jenkins server uses too much CPU or memory

When many users access Jenkins at the same time and it becomes slow

When build queues grow and jobs wait too long to run

When Jenkins logs grow too large and slow down the system

Config File - jenkins.xml

jenkins.xml

<?xml version="1.0" encoding="UTF-8"?>
<jenkins>
  <numExecutors>4</numExecutors>
  <quietPeriod>5</quietPeriod>
  <scmCheckoutRetryCount>2</scmCheckoutRetryCount>
  <workspaceDir>${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}</workspaceDir>
  <buildsDir>${JENKINS_HOME}/builds/${ITEM_FULL_NAME}</buildsDir>
  <systemMessage>Jenkins tuned for better performance</systemMessage>
</jenkins>

numExecutors: Number of parallel jobs Jenkins can run.

quietPeriod: Wait time before starting a job to group changes.

scmCheckoutRetryCount: Number of retries for source code checkout to avoid failures.

workspaceDir and buildsDir: Paths to store job data efficiently.

systemMessage: Shows a message on Jenkins dashboard.

Commands

Starts Jenkins with a maximum of 100 HTTP handler threads to handle more simultaneous requests.

Terminal

java -jar jenkins.war --httpPort=8080 --handlerCountMax=100

Expected Output

Running from: /home/jenkins/jenkins.war

INFO: Jenkins is fully up and running

INFO: HTTP connector started on port 8080

INFO: Maximum handler count set to 100

→

--httpPort=8080 - Sets the HTTP port Jenkins listens on

→

--handlerCountMax=100 - Increases max concurrent HTTP handlers for better performance

Runs a Groovy script via Jenkins CLI to enable performance optimizations like disabling unused plugins.

Terminal

jenkins-cli.jar -s http://localhost:8080 groovy = < enable_performance_optimizations.groovy

Expected Output

Performance optimizations enabled successfully

Restarts Jenkins service to apply configuration and performance changes.

Terminal

systemctl restart jenkins

Expected Output

No output (command runs silently)

Checks the status of Jenkins jobs to verify Jenkins is responsive after tuning.

Terminal

curl -s http://localhost:8080/api/json?tree=jobs[name,color] | jq

Expected Output

{

  "jobs": [

    {"name": "build-app", "color": "blue"},

    {"name": "test-app", "color": "red"}

  ]

}

→

-s - Runs curl silently without progress output

Key Concept

If you remember nothing else from performance tuning Jenkins, remember: adjust executors and resource limits to match your workload.

Common Mistakes

Setting numExecutors too high without enough CPU or memory

Jenkins will overload the server causing slowdowns or crashes

Set numExecutors based on available CPU cores and memory capacity

Not restarting Jenkins after changing configuration

Changes will not take effect until Jenkins restarts

Always restart Jenkins service after config changes

Ignoring plugin performance impact

Unused or heavy plugins can slow Jenkins down

Disable or remove plugins that are not needed

Summary

Start Jenkins with increased handler count to handle more requests.

Configure numExecutors and retry counts in jenkins.xml for better job management.

Restart Jenkins to apply changes and verify responsiveness with API calls.

Practice

1. What is the main purpose of performance tuning in Jenkins?

easy

A. To make Jenkins faster and more reliable

B. To add more plugins to Jenkins

C. To change the Jenkins user interface

D. To increase the number of users who can log in

Solution

1. Step 1: Understand performance tuning goal

   Performance tuning aims to improve speed and reliability of Jenkins.

2. Step 2: Identify correct purpose

   Adding plugins or changing UI does not directly improve performance.

3. Final Answer:

   To make Jenkins faster and more reliable -> Option A

4. Quick Check:

   Performance tuning = faster, reliable Jenkins [OK]

Hint: Performance tuning improves speed and reliability [OK]

Common Mistakes:

• Confusing UI changes with performance tuning
• Thinking adding plugins always improves speed
• Assuming user count affects performance tuning

2. Which Jenkins configuration setting directly controls how many builds can run at the same time on a node?

easy

A. Number of executors

B. Build timeout

C. Build discard policy

D. Workspace cleanup

Solution

1. Step 1: Identify setting for parallel builds

   The number of executors defines how many builds run concurrently on a node.

2. Step 2: Eliminate unrelated options

   Build timeout stops builds after time, discard policy deletes old builds, workspace cleanup removes files.

3. Final Answer:

   Number of executors -> Option A

4. Quick Check:

   Executors = parallel build slots [OK]

Hint: Executors control parallel builds on a node [OK]

Common Mistakes:

• Confusing build timeout with executors
• Mixing discard policy with concurrency
• Thinking workspace cleanup affects build count

3. Given this Jenkins pipeline snippet, what will happen when it runs?

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        parallel {
          stage('Test1') { steps { echo 'Running Test1' } }
          stage('Test2') { steps { echo 'Running Test2' } }
        }
      }
    }
  }
}

medium

A. Test1 and Test2 run one after the other

B. Pipeline fails due to syntax error

C. Test1 and Test2 run at the same time

D. Only Test1 runs

Solution

1. Step 1: Understand parallel block in pipeline

   The parallel block runs multiple stages simultaneously.

2. Step 2: Analyze given stages

   Test1 and Test2 are inside parallel, so both run at the same time.

3. Final Answer:

   Test1 and Test2 run at the same time -> Option C

4. Quick Check:

   parallel block = simultaneous stages [OK]

Hint: parallel block runs stages simultaneously [OK]

Common Mistakes:

• Assuming stages run sequentially by default
• Thinking only one parallel stage runs
• Believing syntax error exists in pipeline

4. You notice Jenkins is slow and builds queue up. Which configuration mistake could cause this?

medium

A. Increasing build retention days

B. Setting number of executors to 1 on a powerful node

C. Enabling parallel pipelines

D. Using lightweight checkout

Solution

1. Step 1: Identify cause of slow builds and queue

   Having only 1 executor limits concurrent builds, causing queue.

2. Step 2: Check other options

   Parallel pipelines improve speed, retention affects storage, lightweight checkout reduces load.

3. Final Answer:

   Setting number of executors to 1 on a powerful node -> Option B

4. Quick Check:

   Too few executors = slow builds [OK]

Hint: Few executors cause build queue delays [OK]

Common Mistakes:

• Thinking parallel pipelines slow Jenkins
• Confusing build retention with performance
• Ignoring executor count impact

5. To improve Jenkins performance on a server with 16GB RAM and 8 CPU cores, which combination is best?

hard

A. Set executors to 4, disable parallel pipelines, and increase build retention days

B. Set executors to 1, disable parallel pipelines, and reduce JVM heap memory

C. Set executors to 16, disable parallel pipelines, and keep default JVM memory

D. Set executors to 8, enable parallel pipelines, and increase JVM heap memory

Solution

1. Step 1: Match executors to CPU cores

   Setting executors to 8 uses all CPU cores efficiently for parallel builds.

2. Step 2: Enable parallel pipelines and increase JVM memory

   Parallel pipelines speed up tasks; more JVM heap memory supports heavier load.

3. Step 3: Evaluate other options

   Lower executors or disabling parallel pipelines reduces performance; build retention affects storage, not speed.

4. Final Answer:

   Set executors to 8, enable parallel pipelines, and increase JVM heap memory -> Option D

5. Quick Check:

   Executors = CPU cores + parallel + memory up = best [OK]

Hint: Match executors to CPU cores and enable parallel pipelines [OK]

Common Mistakes:

• Setting executors too low or too high
• Disabling parallel pipelines unnecessarily
• Confusing build retention with performance tuning