Active choices parameter and active choices reactive reference parameters sooo slow

Using Jenkins
1

Hi all,

First of all, apologize if this question has been already resolved previously. I was not able to find it. Also, I’m a novice configuring Jenkins but I was assigned to fix an issue that has been existing in one of the pipelines that we are using since several months ago

We have a pipeline that is using 26 active choices/active choices reactive parameters. They are using all dropdown lists and will be populated based on the references selected previously.

Some of them (the first two) have the options hardcoded in the Groovy script section and others are retrieving the options from a json file hosted on Github, by using JsonSlurperClassic method, in the Groovy script section.

The problem is when we started to choose the dropdown options. First two dropdowns are already with the following options:

  1. global and project
  2. non-prod and prod

Defaults are “project” and “non-prod”. If I change the first one to “project”, now the second dropdown takes about 20 seconds to display “non-prod” and “prod”.

Once I’m sure about my two choices, things get worse. Dropdowns reading source from Github (that have more than 2 options) also take about 20-30 seconds. Fetch and parse of the json file looks good. I even hardcoded all the options in the 3rd Groovy to see if the problem is the fetch/parse but I’ve got the same results.

Groovy scripts are really simple… Try/catch and they have less than 40 lines per file and the source jsons are less than 1 MB each.

I have been dealing with this since last week and I can’t find what is provoking the dropdowns to be too slow. Running a single job could take up to 3-5 minutes and just imagine if you did a mistake and select the wrong choice. You’ll need to rollback and start it again.

Once well populated, the job runs smoothly and Jenkins is 2.375.2, FYI.

Last but not least, I don’t have permissions to see the Jenkins management console/plugins version, connect to the runners/workers or run this locally :frowning:

I will really appreciate any hint/guidance here. Thanks in advance!

2

Hello @Carlos.Cuevas and welcome to this community :wave:

It sounds like the issue may be related to the amount of data being retrieved and processed by the Active Choices/Active Choices Reactive Parameters. When a parameter is selected, the others may need to reload their options, which could lead to delays if there are many options or the options are retrieved from an external source.

Here are some suggestions you could try:

  1. Check the performance of the Jenkins master and nodes: You mentioned that you don’t have access to the Jenkins management console, but if possible, you could check with your admin if the master and nodes are under heavy load or if there are any performance issues. Is your PC/Browser doing ok by the way? How is your CPU doing when choosing these options?
  2. Optimize the retrieval of options: You mentioned that some of the parameters are retrieving their options from a json file hosted on Github. You could try to optimize this by caching the options or reducing the amount of data being retrieved. For example, you could split the json file into smaller files or only retrieve the options that are relevant based on the previous selections.
  3. Reduce the number of parameters: If possible, you could try to reduce the number of parameters used in the pipeline. This could simplify the pipeline and reduce the amount of data that needs to be processed.

My $0.02. :person_shrugging:

1 Like
3

A bit late, but thanks for your response!

I followed some of your recommendations barely some weeks ago since moving forward to speed up the performance of the job was not critical task. We migrated the cluster to a different cluster (dedicated to less # of jobs)… But the issue was the same.

Suddenly, some time ago, I noted that the job was unusually fast (really, REALLY fast) but some users started to complain that some of the fields were showing ERROR or returning the catch message. Also, debugging, I found this issue on an active choice reactive reference parameter that is suppose to be a checkbox:

java.lang.IllegalArgumentException: The JSON input text should neither be null nor empty.

When I was running debugging why suddenly this started to fail without touching the Groovy files, one of my colleagues who also manage the Jenkins cluster, told me that he updated the Active Choices plugin from 2.6 to a higher version. Gotcha, it made the job faster… But now is not 100% useful. Some ACRRP are not being updated based on other controls choice change. I’m trying to figure out which one of the changes described at active-choices-plugin/CHANGES.md at 5198d6292b47b5284caf67e6ecb0252264793aaf · jenkinsci/active-choices-plugin · GitHub could break the functionality of the job.

If I play with some of the dropdown changing options randomly (not the expected way to use the job, fyi) to update other active choices, at some point, all the fields that should be there depending on previous choices are there, but this is like 5% of the times I play with the fields.

I will keep an eye trying to find why upgrading from 2.6.x to 2.7 broke this, maybe I could find something interesting but as usual, any help is always appreciated!

Carlos

4

I’m one of the contributors to the AC plugin. Versions past 2.6 have update issues as recent code changes were introduced . I exclusively use AC plugin with freestyle jobs, and I will not upgrade to any version >2.6 anytime soon. Stick with that. Perhaps slow but ALWAYS works as intended! :shushing_face: Hopefully @kinow will fix these regression issues as time permits