This content has been marked as final. Show 3 replies
I don't think the example you are looking at will make much difference either way in terms of performance, although I'd say the only reliable way to know is to test. Things like wildcards in targetDNs are much more expensive.
ACI consolidation is also about simplifying the ACIs so they are easier to administer. I'd try to keep the organization as consistent as possible. If you are going to have a lot of users and groups that get access to the same resource/s, you might want to keep those separate.
Thanks for the tip. In the system we're looking at, they have a huge number of ACIs (around 500 in some of their environments) and we're looking for ways to reduce the number of ACIs the system has to check to improve performance. Unfortunately, without more knowledge of their system than I currently have, the only ways I've been able to think of the do that is to remove or combine access controls to lighten the load. But I'll keep what you said in mind going forward.
Remember that placement of ACIs is important.
When accessing an entry the server collects all the ACIs on the path between the root suffix and the entry, and processes those ACIs.
Now, you can collect al your ACIs together and place them on the suffix, but there are a couple of potential drawbacks:
1) Do you really want all of the ACIs to affect the entire DIT? Or do you want to restrict a given ACI to a specific sub-tree? If its the latter, place it on the sub-tree.
2) If you put all the ACIs on the suffix, every one of them will potentially be processed for every request. This can have a noticeable performance impact. By placing them close to where their effect is required, you limit their scope, and the number of times they get processed.
Also keep in mind that other than affecting scope, placement has no effect on order of processing.