Jenkins is very slow on the first visit in the early morning. This also happens if we restart the Jenkins server.
So the first developer accessing the jenkins has sometimes wait up to 3 minutes.
We thought it was an issue with the build load. So we moved all build-jobs to a jenkins slave. But the issue has not been solved with it.
Since the performance seems to be always bad after restart. I assume jenkins reads a lot of stuff into memory.
How can we enforce jenkins to precache stuff? We can give jenkins a hughe amount of RAM if needed. Hopefully the cache will solve the speed issues.
It would be difficult to definitively say what is causing your Jenkins instance to take so long to startup, though it is highly likely that one of your installed plugins is the offender.
For example:
JENKINS-17837 - Downstream Build View Plugin
JENKINS-24945 - Global Build Stats Plugin
Surely there are other plugins besides these two which have bugs/issues resulting in slow startup times as well. Some may have had issues and subsequent versions have addressed the performance issues.
Therefore, performing the following steps should at least reveal the culprit if not entirely fix the issue:
Upgrade Jenkins to the latest, stable version
Upgrade all plugins to their latest, stable versions
Restart Jenkins
If startup remains slow, remove your plugins one at a time (ensuring to save their respective configurations if necessary)
If upgrading to the latest versions does not improve your startup time, step 4 should reveal the culprit.
Related
I may be approaching the new Cache pipeline task the wrong way, but I'm trying to improve the Build task. Currently, the build task takes on average 20 minutes to complete. I've been reading about the new Cache task, but it seems that would help with caching items like Nuget and npm libraries which for us is in a different task and only takes 1 minute.
Is there a cache setup that can help with the build itself?
Caching is especially useful in scenarios where the same dependencies are downloaded over and over at the start of each run. This is often a time consuming process involving hundreds or thousands of network calls.
Caching can be effective at improving build time provided the time to restore and save the cache is less than the time to produce the output again from scratch. Because of this, caching may not be effective in all scenarios and may actually have a negative impact on build time.
Please refer to this document for details.
Here are two other ways to reduce build time:
You can try to reduce build time in CI pipelines through parallel builds. Here are the reference: blog1,blog2.
In order to obtain faster performance, you can use private agent to run the build pipeline, as private agents cache everything between builds. If you do need to clean the repo (for example to avoid problems caused by residual files from a previous build), you can select Clean option in build definition.
.NET/NuGet:
If you use PackageReferences to manage NuGet dependencies directly within your project file and have packages.lock.json file(s), you can enable caching by setting the NUGET_PACKAGES environment variable to a path under $(Pipeline.Workspace) and caching this directory.
I am suffering the slow download of maven.
I use the default configuration for Spring Boot starter project.
Group: com.example
Artifact: Demo
STS takes too much time to sync the content. is there a way to speed this up? for example, download the whole thing separately that the project needs, and then import them locally.
If you look carefully at the screenshot you'll notice that it says that Maven download operation is blocked by user operation.
The comments saying the build is slower under IDE (particularly Eclipse) are wrong in the sense that they are sort of a mental shortcuts. They are based on observation (it may indeed take longer time to achieve the end result) but that does not mean the build/download itself is slower. The thing is that Eclipse performs way more operations than just the build alone and sometimes those end up waiting on one another (as your screenshot clearly indicates).
With that in mind, if you run your build on the command line it may complete a lot faster as most likely it will not compete for resources with other tasks. But keep in mind that will keep Eclipse out of sync with what is actually on the file system. Eventually Eclipse will figure that out and try to sync. Sometimes it may not and you would have to do it manually. In both cases, depending on the size and amount of the projects and the number and complexity of changes made, it may take significant time to sync.
To summarize, it's not "slow download of maven" what you experience but multiple tasks competing for resources and waiting on each other. There is no point to pre-download all dependencies as this is not a recurring operation. Maven ONLY downloads missing dependencies. Once they are in local repo it will not try to download them again (unless you force it to).
We have had occurrences where a SonarQube job is running for hours, appears to be hung with no ETA on its completion in our CI environment. We have used a workaround solution of not only aborting the build job, but there seems to be a secondary process executing SonarQube on the CI agent itself. I have read that specifying sonar.forceAnalysis=true should resolve the issue but this has been deprecated as of version 3.X and there is no need to use this analysis parameter. We would like to be able to proactively address this and not have to respond after a team running SonarQube notifies us of this issue. Is there some way of specifying a timeout where the process running the analysis will just terminate?
If you are looking for killing the analysis running in your CI environment after a certain time, I would suggest you look into the feature offered by your CI environment.
There is no such thing in SonarQube.
As a side note, you should have a look into the upcoming 5.2 release of SonarQube. We have cut the connection to the database from the analyzer which means the error “The project already being analyzed” can not occur any more. In addition, quite a bunch of work done by the analysis job has been moved to the server which allow it to run faster.
I need solution to speed up maven build process.
The project is based on Adobe cq5 otherwise AEM and i have more than 10 modules in my project where the build happens in linear way.
Currently Build process takes more than 10 min to compile.
is any other specific tool available or other way to speed up the process?
Thanks
I have one suggestion,If you have 10 modules than make separate profile for each module,and build only that part in which you are changing and modifying,no need to deploy 10 modules each time unnecessarily.It will not speed up maven project build but can help you to save your time.It is a workaround but will be helpful .
Try mvn -T 4 clean install #Builds with 4 threads
Its a multi-threaded mode to run Maven and is faster. Apache documentation here.
To add to the other answers:
1) Give more memory resources to the server where the AEM instance is installed, content creation involves a lot of disk access so using SSD is a must.
2) Having a clean AEM instance helps to speed up the process. As you may know the AEM repository grows because of revisions so each time you deploy the repository size grows and it becomes slower. if it's a production environment use maintenance tools like revision clean up and compaction.
revision clean up
how to maintain repository
As per my knowledge there are no such mechanism to speed up.
better to make a build of particular module, it will deploy faster rather waiting for all 10 module to be happened.
Thanks
You can try using the suggested answers to build modules in parallel. It should speed up the build in theory.
But really there is no magic answer. You have to find the bottleneck in your build, it could be the number of dependencies, it could be a specific slow plugin, it could be hardware related, and it could be something else.
Try this: https://github.com/lptr/maven-time-tracker
It may help you find the bottleneck.
I would like to answer this question, knowing it was posted a really long time back.
Currently I am using AEM 6.3 and to recompile and deploy CORE module changes there is a simple maven trick -
This command tells us to -
run 1 thread/core
compile just the core module of the list of projects
and of course, zip package and send it to running AEM instance.
In my observation, this reduced the turnaround time by a huge margin.
It is around 10 months now that Jenkins split off from Hudson.
When looking at the project homepages I am wondering what the differences between Hudson and Jenkins in the meantime really are. From the changelog I do not realy learn much. There are a bunch of changes and the major difference seems to be that Jenkins releases more often with less changes and Hudson less frequently, but then with more changes in a release.
Are there any notable differences yet?
So are there things that make me as a developer needing a CI system more productive rather with the one or the other?
Is one of them more stable than the other?
Is there any difference yet that has nothing to do with politics around Oracle?
What is the most notable difference from your point of view?
One notable difference is that a big number of plugins moved to Jenkins. While you would still be able to use the old versions with Hudson, the newer versions depend on Jenkins already. Also new plugins are mostly created with dependencies on quite recent Jenkins versions, so you probably won't be able to use them without hassle on Hudson.
This will probably differ from plugin to plugin, some might be more compatible with Hudson than others, while still others provide versions for both tools. But if something does not work well with a plugin you will receive help easier if you use Jenkins.
EDIT: Here is an interesting link I found, not only providing some solid numbers on the different paths Jenkins and Hudson have taken, but also addressing the (non-)issue of IP that was mentioned in the other post here...
check out the work being done on cleaning up the code and the IP checks that are needed to belong to Eclipse Foundation. This is one of the big differentiators if you care about clean IP.
How many plugins are you using? Hudson supports many of the most important plugins independently and is working with plugin owners to keep compatibility with those that are still maintained by their owners at Jenkins.
See the JavaOne presentations that show how Hudson is being maintained and new features added.
https://oracleus.wingateweb.com/scheduler/eventcatalog/eventCatalogJavaOne.do (search for Hudson)
Also check out the Hudson project at Eclipse http://www.eclipse.org/hudson/