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?
Thank you, Adrian
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi Rich,
Sorry for missing this info. It's 1.2.11 running on SL6.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@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).
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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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).
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@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@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).
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@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
On 10/01/2015 02:53 PM, Rich Megginson wrote:
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.
Hmmm. Interesting.
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?
Yes, all the entries at level one in the subtree of a node. The root node is Groups and the subtree nodes are the actual groups. I want to be able to list the names of the groups.
operation that is not affected by the macro ACIs.
Not sure what you mean here.
The macro ACIs grant access to other attributes and are not required to be evaluated for this list/read operation to work correctly.
I was thinking of a multi value attribute in the root node
The DSE root entry ""? The entry at the base of the suffix?
The root Groups node for which I want to be able to display the name of the group elements of the subtree.
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.
Fair enough. That could be achieved in the client software - I was just hoping I could avoid that.
Adrian
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).
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@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-users@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Adrian Damian -
Noriko Hosoi -
Rich Megginson