Hello Rich and Noriko,
Is there a work around to slow listing or children problem? All I need
is to list their IDs (entrydn or cn or uid), operation that is not
affected by the macro ACIs. I was thinking of a multi value attribute in
the root node 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?
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