Qlik Community

Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

Announcements
Now Live: Qlik Sense SaaS Simplified Authoring – Analytics Creation for Everyone: READ DETAILS
cancel
Showing results for 
Search instead for 
Did you mean: 
gandalfgray
Specialist II
Specialist II

Security rule efficiency - 1 complex vs 2 simpler

Hi!

Is there any significant difference in performance splitting a "complex" security rule into two simpler?

If so, which is better for performance?

Example:

A (one rule):

((user.group=resource.@access_group) and (user.group="data.access.qs.superuser" or user.group="data.access.qs.poweruser"))

 

B1 (first of two rules):

((user.group=resource.@access_group and user.group="data.access.qs.superuser"))

B2 (second of two rules):

((user.group=resource.@access_group and user.group="data.access.qs.poweruser"))

Labels (1)
2 Solutions

Accepted Solutions
Marc
Employee
Employee

Order of execution in rule syntax matters  (Examples 5 & 6) so it would actually be more performant to do it this way, so that the Rule Fails if the user is not in the Groups without having to resolve the custom property value 

((user.group="data.access.qs.superuser" or user.group="data.access.qs.poweruser") and (user.group=resource.@access_group))

View solution in original post

Marc
Employee
Employee

In the scenario where the user matches against the first rule, there will be a very slight difference in performance.

if they match against the second rule there is a greater increase in overhead 

and if they don't match against either rule then there is more overhead again.

if the user was in both superuser & poweruser groups, but not in the resource.@access_group the overhead would be even higher again.

 

so yes, there would be greater overhead having two rules instead of one.

 

Rules should fail fast, with the least expensive operations first.

Should be as concise and targeted as possible

Should not use LIKE unless absolutely necessary (this adds significant performance overhead) 

 

 

View solution in original post

3 Replies
Marc
Employee
Employee

Order of execution in rule syntax matters  (Examples 5 & 6) so it would actually be more performant to do it this way, so that the Rule Fails if the user is not in the Groups without having to resolve the custom property value 

((user.group="data.access.qs.superuser" or user.group="data.access.qs.poweruser") and (user.group=resource.@access_group))

gandalfgray
Specialist II
Specialist II
Author

Ok, thanks @Marc  I see,

but then again, is there any significant performance difference between your suggested single rule and having the following two rules instead?:

R1:

((user.group="data.access.qs.superuser") and (user.group=resource.@access_group))

R2:

((user.group="data.access.qs.poweruser") and (user.group=resource.@access_group))

 

If these two has the exact same Resource filter, Actions and Context, and the first evaluated rule returns True is the second rule not evaluated?

Marc
Employee
Employee

In the scenario where the user matches against the first rule, there will be a very slight difference in performance.

if they match against the second rule there is a greater increase in overhead 

and if they don't match against either rule then there is more overhead again.

if the user was in both superuser & poweruser groups, but not in the resource.@access_group the overhead would be even higher again.

 

so yes, there would be greater overhead having two rules instead of one.

 

Rules should fail fast, with the least expensive operations first.

Should be as concise and targeted as possible

Should not use LIKE unless absolutely necessary (this adds significant performance overhead)