schedule2(Task, int, List)
. Since the number of downstream builds of the same project (with different parameter) may achieve range (200-1000) I recognize performance issue. Are you talking about 200-1000 jobs configured, or running simultaneously?
Clients feed log data and artifacts to the Jenkins server in real time. If you’re running hundreds of these simultaneously, you are using tons of threads, tons of RAM for buffers, and tons of disk revolutions. At this point, you can start thinking of your Jenkins server as a database server and determine your hardware requirements accordingly. It’s fairly easy to become I/O bound, and you might become network bound if you’re using older, slower networking.
Also, how is your polling? If you have hundreds of jobs polling, think of those as hundreds of “mini-jobs” querying source control on a regular basis. They don’t show up in the regular build logs, but they have similar resource needs. If there’s a way to avoid polling (we use GitLab and have a plugin which lets GitLab push updates to Jenkins rather than have Jenkins poll), consider it.
The guys at Cloudbees would be willing to sell you a way to do this using multiple Jenkins servers and have them all centrally managed; you may want to talk to them if this is that big of a project.
--Rob
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/bb6d5973-f2e1-4326-843e-5a20af42443a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Click here to report this email as spam.