Jenkins GUI only shown after waiting for 2 minutes

Question

My Jenkins version is Jenkins 1.508. Some googling around seemed to indicate that I needed a small change in my jenkins.xml (see for instance http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html), but that xml change did not help a lot in my case. Today I installed the monitoring plugin, and can see that jenkins needed 112,978 ms to respond to my request, where should I look for the culprit?

Answer 1

I would recommend checking a couple different things.

1. Is the jenkins process pegged at 100% CPU or higher? This could indicate that there are, for example, too many builds being kept around (Jenkins seems to have trouble with this; I usually keep no more than 25 builds per job to help prevent performance issues from this). I've noticed the Performance plugin can also lead to intense CPU usage, especially when it is drawing the graphs (which Jenkins does not cache nor save to disk, so each page load they need to be recreated).

2. What does the Jenkins access log say? Does it quickly register your request but then sit there seemingly doing nothing? If this is the case and the CPU isn't pegged on the jenkins process, it may be a browser issue.

I found that pages weren't loading even after 5+ minutes, but there was seemingly no jenkins-based load on the server, nor any serious load on the box elsewhere. I had been using Firefox to access the pages, and when I tried the same page in Chrome, it loaded instantly. I could then go back to Firefox and it again would not load. So there was something wrong at that point in time with the browser with respect to Jenkins (not sure quite what it was). So now I generally use Chrome to access Jenkins and haven't really noticed slow/non-loading pages since.

Edit in response to comment from OP:

To clean up old builds, I employ a two-phase process:

1. Navigate to the jobs directory of your Jenkins install and then into the builds directories of each job you want to clean up. From there simply delete the directories of the builds you no longer want (using whatever shell tools you prefer -- find, etc.) If too many builds is the issue, cleaning these up at the file system level should then allow Jenkins pages and views to load.
2. If the cleanup then allows you to load the pages for the jobs, you can then click the Configure action to change the config and select the option to keep a limited number of builds, setting it to a lower value, such as 25.

If the jenkins process isn't pegged at a high CPU number, it seems somewhat unlikely that it's the number of builds that are the issue, but it's probably worth a try. If you think you may want the build info back later, simply move them to a location outside the jobs folder hierarchy instead of deleting them and Jenkins won't know about them. You can always move it back later.

It's probably best to do the file-level moving with Jenkins stopped, and then reload it once the cleanup is done. It will then have far fewer builds to iterate over.

Edit in response to follow-up comment from OP:

Re: point 1, that definitely sounds like there might be an issue with the installation (cross-linked separate installs, or something like that).

Re: point 2: That will depend in part on how Jenkins was installed. i.e. is it running on Tomcat, or with standalone?

Re: point 3: This really sounds like you might have cross-linked installs. If you stopped Jenkins, the GUI really should no longer work.

Re: point 4: 11 seconds is certainly a huge improvement over 2 minutes. That definitely suggests that too many kept-builds was one problem, but the pages really should be pretty snappy to load on a relatively idle system, so it sounds like there may potentially be some other issues as well, particularly a cross-linked install of sorts.

Is there ever more than one jenkins process running? Is Tomcat involved?

Edit in response to OP's follow-up comment:

Given your comments about not recalling the details of the original installation, I think it may be best to simply install Jenkins from scratch using the self-contained (i.e. non-Tomcat) method, and then migrate your data from the old install as I mentioned previously, copying the whole jobs directory elsewhere first just in case.

This way you can be sure of the installation details and get to keep the data.

Answer 2

In my experience its related to Windows file system being really bad at handling folders with a lot of sub folders. Loading a View could take up to a minute.

We made our Jenkins Views fast again by reducing the default builds stored per job and delete the old builds as suggested by khampson.

I would expect a Jenkins running on Linux to be much better at handle big number of builds