Condition builder makes time consuming duplicate sequential requests to the instance, when the same choice-list type field is used multiple times in the filter (particularly impacting CMDB Class-based filters) - Known Error

Condition builder makes time consuming duplicate sequential requests to the instance, when the same choice-list type field is used multiple times in the filter (particularly impacting CMDB Class-based filters) Description When Condition builder is used to query multiple identical or similar queries in PickList it sends all calls separately, and sequentially. Where the choicelist returned is identical, these are duplicate and unnecessary, and just add to the time.

This causes significant delay on pages where a large number of the query is used.

e.g. Choice list Field is A, OR Choice list Field is B, or Choice list Field is C. "Field" has the same choice list each time, so the choices don't need re-requesting from the instance

Worst case scenario of a large number of choices, and the same filter condition repeated many times, is quite common in CMDB features. The CMDB extended usually has >1000 different table classes, and filters tend to include entries for many different classes. for example: - CI Relationship Editor Filter, derived from Suggested relationships - CMDB Health Inclusion rules, for specifying which CI Classes to include in health jobs - Reference Qualifiers for CMDB reference fields, for filtering list popups to specific Classes

Currently, there is no mechanism to re-use the choices from one field, and re-use that response for all the other bits of the condition that are for the same field. The client-side class "GlideFilterHandlers.js" does not cache identical calls.

Symptoms:

For the CMDB Relationships Editor symptom, and the ways to debug and confirm this is what is causing the performance issue in general, see KB1121632 CMDB Relationship Editor is very slow to (re)load the Filter

Steps to Reproduce

1/ Open the Dictionary record for the task table, cmdb_ci field, which is a reference field to the cmdb table 2/ Change "Use reference qualifier" to "Simple" 3/ In the condition builder, enter this: Class is --None-- (then just click "OR" 19 times and wait for it to catch up) or, Class is --None-- or, Class is --None-- or, Class is --None-- or, Class is --None-- .. until you have added 20

4/ Turn on browser developers tools, and select the Network tab 5/ Save 6/ Watch in the browser debug as that dictionary record form saves and then reloads.

You will see a set of 20 sequential and identical PickList requests, each taking a second or more, then as the form re-loads another 2 sets. It'll start to reload at ~50s, have done a second set by ~96s, and finished after another set by ~137s

Inspect the PickList request headers and results, and you will see they are identical. All but the first is duplication.

Each request does take a significant amount of time by themselves in this cmdb class field example (1.7s each in this test, and longer in some customers), so it is important we should only have to do it once.

Workaround This problem has been fixed. If you are able to upgrade, review the Fixed In section to determine the latest version with a permanent fix your instance can be upgraded to.