Les calculateurs et les règles d’affectation utilisent des conditions pendant l’importation, créées à l’aide du créateur de condition. Les changements apportés à leurs critères peuvent affecter les performances, car chaque enregistrement est évalué à l’aide de ces filtres.

Les règles et calculateurs fournis avec le système de base sont optimisés en termes de performances. L’édition ou la création de règles ou de calculatrices prend soin et peut nécessiter les deux ServiceNow et Application Vulnerability Response une expertise. Cela dit, il existe des conseils.

Éviter le filtrage basé sur les champs de sous-classe

Certaines tables prennent en charge l’extension. La table CI [cmdb_ci] de la CMDB en est un exemple. Les tables telles que cmdb_ci_hardware et cmdb_ci_computer étendent cette table. Si vous appliquez un filtre en fonction d’un champ qui ne figure pas dans la table parente, la création et l’évaluation de ce filtre peuvent s’avérer coûteuses.

Par exemple, filtrer sur ID d’élément de configuration > Coût n’affecterait pas négativement les performances, car Coût est un champ de classe, et non un champ de sous-classe, de l’élément de configuration.

ID d’élément de configuration > Ordinateur, cependant, est une sous-classe nécessitant une remontée pas à pas vers un autre champ, dans ce cas, Operating System. Ce processus peut prendre plusieurs millisecondes, ce qui s’additionne rapidement, lorsque des millions d’éléments vulnérables sont importés, et affecte les performances.

Remarque :

L’utilisation de la condition [contains] s’apparente à une recherche générique et peut avoir un impact sur les performances. L’utilisation de [is], dans la mesure du possible, est plus efficace.