On 09/16/2015 03:11 PM, Adrian Damian wrote: > Hi There, > > The scenario is simple: we have a subtree in the DIT with a few thousand > children node. The parent node of the subtree has a few acis including a > couple of macro acis that apply to each of the child nodes. We've > observed a significant performance degradation when trying to list all > the children in the presence of the macro acis. > > Profiling on the client code show that although the first few child > nodes were fetched quite fast there is a clear delay buildup as the > retrieval progresses. The buildup is not present when the macro acis are > removed. Also, it is faster to split the list in chunks and retrieve > them sequentially. > > Is it possible that as the macro acis are resolved they are added to the > list of acis of the parent node so that the last nodes are evaluated > against many more acis than the first ones and hence the observed delay > in their retrieval? Is there a workaround for this? What version of 389? rpm -q 389-ds-base > > Thank you, > Adrian > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

On 09/17/2015 10:52 AM, Adrian Damian wrote: > Hi Rich, > > Sorry for missing this info. It's 1.2.11 running on SL6. We need the exact version, which is why I asked for the output of rpm -q 389-ds-base > Adrian > > On 09/17/2015 08:54 AM, Rich Megginson wrote: >> On 09/16/2015 03:11 PM, Adrian Damian wrote: >>> Hi There, >>> >>> The scenario is simple: we have a subtree in the DIT with a few >>> thousand >>> children node. The parent node of the subtree has a few acis >>> including a >>> couple of macro acis that apply to each of the child nodes. We've >>> observed a significant performance degradation when trying to list all >>> the children in the presence of the macro acis. >>> >>> Profiling on the client code show that although the first few child >>> nodes were fetched quite fast there is a clear delay buildup as the >>> retrieval progresses. The buildup is not present when the macro acis >>> are >>> removed. Also, it is faster to split the list in chunks and retrieve >>> them sequentially. >>> >>> Is it possible that as the macro acis are resolved they are added to >>> the >>> list of acis of the parent node so that the last nodes are evaluated >>> against many more acis than the first ones and hence the observed delay >>> in their retrieval? Is there a workaround for this? >> What version of 389? rpm -q 389-ds-base >> >>> Thank you, >>> Adrian >>> >>> -- >>> 389 users mailing list >>> 389-users(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

Hello, There is a known issue in the macro aci performance which is fixed in the upstream. The fix will be included in the next rhel releases (6.8 and 7.2).

Thanks, --noriko On 09/17/2015 09:59 AM, Adrian Damian wrote: > 389-ds-base-1.2.11.15-34.el6_5.x86_64 > > On 09/17/2015 09:56 AM, Rich Megginson wrote: >> On 09/17/2015 10:52 AM, Adrian Damian wrote: >>> Hi Rich, >>> >>> Sorry for missing this info. It's 1.2.11 running on SL6. >> We need the exact version, which is why I asked for the output of >> rpm -q >> 389-ds-base >> >>> Adrian >>> >>> On 09/17/2015 08:54 AM, Rich Megginson wrote: >>>> On 09/16/2015 03:11 PM, Adrian Damian wrote: >>>>> Hi There, >>>>> >>>>> The scenario is simple: we have a subtree in the DIT with a few >>>>> thousand >>>>> children node. The parent node of the subtree has a few acis >>>>> including a >>>>> couple of macro acis that apply to each of the child nodes. We've >>>>> observed a significant performance degradation when trying to >>>>> list all >>>>> the children in the presence of the macro acis. >>>>> >>>>> Profiling on the client code show that although the first few child >>>>> nodes were fetched quite fast there is a clear delay buildup as the >>>>> retrieval progresses. The buildup is not present when the macro acis >>>>> are >>>>> removed. Also, it is faster to split the list in chunks and retrieve >>>>> them sequentially. >>>>> >>>>> Is it possible that as the macro acis are resolved they are added to >>>>> the >>>>> list of acis of the parent node so that the last nodes are evaluated >>>>> against many more acis than the first ones and hence the observed >>>>> delay >>>>> in their retrieval? Is there a workaround for this? >>>> What version of 389? rpm -q 389-ds-base >>>> >>>>> Thank you, >>>>> Adrian >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-users(a)lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

On 09/17/2015 10:39 AM, Rich Megginson wrote: > On 09/17/2015 11:33 AM, Noriko Hosoi wrote: >> Hello, >> >> There is a known issue in the macro aci performance which is fixed in >> the upstream. The fix will be included in the next rhel releases >> (6.8 and 7.2). >> > https://fedorahosted.org/389/ticket/48141 And https://fedorahosted.org/389/ticket/48175 >> Thanks, >> --noriko >> >> On 09/17/2015 09:59 AM, Adrian Damian wrote: >>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>> >>> On 09/17/2015 09:56 AM, Rich Megginson wrote: >>>> On 09/17/2015 10:52 AM, Adrian Damian wrote: >>>>> Hi Rich, >>>>> >>>>> Sorry for missing this info. It's 1.2.11 running on SL6. >>>> We need the exact version, which is why I asked for the output of >>>> rpm -q >>>> 389-ds-base >>>> >>>>> Adrian >>>>> >>>>> On 09/17/2015 08:54 AM, Rich Megginson wrote: >>>>>> On 09/16/2015 03:11 PM, Adrian Damian wrote: >>>>>>> Hi There, >>>>>>> >>>>>>> The scenario is simple: we have a subtree in the DIT with a few >>>>>>> thousand >>>>>>> children node. The parent node of the subtree has a few acis >>>>>>> including a >>>>>>> couple of macro acis that apply to each of the child nodes. We've >>>>>>> observed a significant performance degradation when trying to >>>>>>> list all >>>>>>> the children in the presence of the macro acis. >>>>>>> >>>>>>> Profiling on the client code show that although the first few child >>>>>>> nodes were fetched quite fast there is a clear delay buildup as the >>>>>>> retrieval progresses. The buildup is not present when the macro >>>>>>> acis >>>>>>> are >>>>>>> removed. Also, it is faster to split the list in chunks and >>>>>>> retrieve >>>>>>> them sequentially. >>>>>>> >>>>>>> Is it possible that as the macro acis are resolved they are >>>>>>> added to >>>>>>> the >>>>>>> list of acis of the parent node so that the last nodes are >>>>>>> evaluated >>>>>>> against many more acis than the first ones and hence the >>>>>>> observed delay >>>>>>> in their retrieval? Is there a workaround for this? >>>>>> What version of 389? rpm -q 389-ds-base >>>>>> >>>>>>> Thank you, >>>>>>> Adrian >>>>>>> >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> 389-users(a)lists.fedoraproject.org >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> -- >>>>>> 389 users mailing list >>>>>> 389-users(a)lists.fedoraproject.org >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> -- >>>>> 389 users mailing list >>>>> 389-users(a)lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

On 10/01/2015 02:58 PM, Adrian Damian wrote: > Hello Rich and Noriko, > > Is there a work around to slow listing or children problem? You could use cn=Directory Manager which is not affected by ACIs.

> All I need is to list their IDs (entrydn or cn or uid), To what does "their" refer to? macro acis? All entries in the subtree?

> operation that is not affected by the macro ACIs. Not sure what you mean here.

> I was thinking of a multi value attribute in the root node The DSE root entry ""? The entry at the base of the suffix?

> that contains the IDs of all the children.Is there a plugin that can > update this attribute automatically when an new child entry is added > or deleted to the base node? No.

> Thanks, > Adrian > > > On 09/17/2015 10:44 AM, Noriko Hosoi wrote: >> On 09/17/2015 10:39 AM, Rich Megginson wrote: >>> On 09/17/2015 11:33 AM, Noriko Hosoi wrote: >>>> Hello, >>>> >>>> There is a known issue in the macro aci performance which is fixed in >>>> the upstream. The fix will be included in the next rhel releases >>>> (6.8 and 7.2). >>>> >>> https://fedorahosted.org/389/ticket/48141 >> And https://fedorahosted.org/389/ticket/48175 >>>> Thanks, >>>> --noriko >>>> >>>> On 09/17/2015 09:59 AM, Adrian Damian wrote: >>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>>> >>>>> On 09/17/2015 09:56 AM, Rich Megginson wrote: >>>>>> On 09/17/2015 10:52 AM, Adrian Damian wrote: >>>>>>> Hi Rich, >>>>>>> >>>>>>> Sorry for missing this info. It's 1.2.11 running on SL6. >>>>>> We need the exact version, which is why I asked for the output of >>>>>> rpm -q >>>>>> 389-ds-base >>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On 09/17/2015 08:54 AM, Rich Megginson wrote: >>>>>>>> On 09/16/2015 03:11 PM, Adrian Damian wrote: >>>>>>>>> Hi There, >>>>>>>>> >>>>>>>>> The scenario is simple: we have a subtree in the DIT with a few >>>>>>>>> thousand >>>>>>>>> children node. The parent node of the subtree has a few acis >>>>>>>>> including a >>>>>>>>> couple of macro acis that apply to each of the child nodes. We've >>>>>>>>> observed a significant performance degradation when trying to >>>>>>>>> list all >>>>>>>>> the children in the presence of the macro acis. >>>>>>>>> >>>>>>>>> Profiling on the client code show that although the first few >>>>>>>>> child >>>>>>>>> nodes were fetched quite fast there is a clear delay buildup >>>>>>>>> as the >>>>>>>>> retrieval progresses. The buildup is not present when the macro >>>>>>>>> acis >>>>>>>>> are >>>>>>>>> removed. Also, it is faster to split the list in chunks and >>>>>>>>> retrieve >>>>>>>>> them sequentially. >>>>>>>>> >>>>>>>>> Is it possible that as the macro acis are resolved they are >>>>>>>>> added to >>>>>>>>> the >>>>>>>>> list of acis of the parent node so that the last nodes are >>>>>>>>> evaluated >>>>>>>>> against many more acis than the first ones and hence the >>>>>>>>> observed delay >>>>>>>>> in their retrieval? Is there a workaround for this? >>>>>>>> What version of 389? rpm -q 389-ds-base >>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 389 users mailing list >>>>>>>>> 389-users(a)lists.fedoraproject.org >>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>>> -- >>>>>>>> 389 users mailing list >>>>>>>> 389-users(a)lists.fedoraproject.org >>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> 389-users(a)lists.fedoraproject.org >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> -- >>>>>> 389 users mailing list >>>>>> 389-users(a)lists.fedoraproject.org >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> -- >>>>> 389 users mailing list >>>>> 389-users(a)lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users