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

We have implemented a quick and dirty work around. Just create a job in Jenkins which periodically invokes the following shell script:

wget http://localhost:8080/view/All/ -O /dev/null

This reduces the load times for all views (since Jenkins has to take the hit himself) for our users.

As stated in the comment the wget only loads the job view. In order to interate all jobs we are using the following curl script (Linux based host):

Jenkins 1.x;

for x in ` curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' |  sed 's/<\/url>//g' | sed 's/<job>//g'| sed 's/<job>//g' | sed 's/<\/job>//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done

Jenkins 2.x;

for x in `  curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' |  sed 's/<\/url.*//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done

You can of course to the same thing for views (http://localhost:8080/api/xml?tree=views[url])

Answer 2

This may not be the problem for the original poster, but I hope it might help others who land here via a web search. In our Jenkins’ case the massive UI slowdown turned out to be a network issue. I’d moved the server to a temporary location during an office move, where the setting in Jenkins Location/Jenkins URL would fail. Setting it temporarily to hostname.local returned page loading to normal.

Answer 3

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 4

I was having the same issue with multiple LTS Jenkins versions, running as a Windows service. Oddly enough, launching Chrome in incognito mode then browsing to the Jenkins URL has Jenkins loading significantly faster. It was taking about 1 minute to paint for multiple users, but in incognito mode it takes less than 5 seconds. I'm not sure why the cache is such an issue. Clearing the cache resolves the issue for a short time, but it starts again within a couple hours, so incognito mode is the way to go.

Answer 5

After upgrading Jenkins to version 1.568, and cleaning up the job directories, the typical response time on a first call of the day is down to about 20 seconds. I think the 'first call of the day' is important here, because when I then go to another machine, the GUI renders immediately there. This might be related to the company proxy, caching mechanisms here and there, or the internal jenkins implementation, but I can live with the current situation.

Answer 6

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