[389-users] Increase in search time operation in 1.2.11 vs 1.2.5

[Ludwig Krispenz]

Hi,

I don't know what has changed since 1.2.5, but aci caching always was a 
difficult area, it tends to cache results of aci evaluation, but there 
have been cases where this was incorrect, so  the different behaviour 
could be teh effect of some bug fixing. but this is speculation,. we 
would need to get all your acis and then verify if handling is correct 
or not.
If you want to do this, please open a ticket and provide all necessary data

Ludwig

On 11/26/2014 01:04 PM, Bartek wrote:
> I manage to come across the following piece of code (aci.c):
>
> /* get the acl */
> acl_info[0] = '\0';
> if (acl_reason->deciding_aci) {
> if (acl_reason->reason == ACL_REASON_RESULT_CACHED_DENY ||
> acl_reason->reason == ACL_REASON_RESULT_CACHED_ALLOW) {
> /* acl is in cache. Its detail must have been printed before.
> * So no need to print out acl detail this time.
> */
> PR_snprintf( &acl_info[0], BUFSIZ, "%s by aci(%d)",
> access_reason,
> acl_reason->deciding_aci->aci_index);
> }
> else {
> PR_snprintf( &acl_info[0], BUFSIZ, "%s by aci(%d): aciname=%s, 
> acidn=\"%s\"",
> access_reason,
> acl_reason->deciding_aci->aci_index,
> acl_reason->deciding_aci->aclName,
> slapi_sdn_get_ndn (acl_reason->deciding_aci->aci_sdn) );
> }
> }
>
> Looking at logs i've posted formely it seems to me that aci's are not 
> cached hence "cached allow by aci(7)" entries in logs. According to 
> the code above if they were cached there would be an "cached 
> context/parent allow" in log (ACL_REASON_RESULT_CACHED_ALLOW would 
> evaluate to true).
>
> I dug through documentation but still there's no trace of a property 
> in "cn=config" etc i'm missing that would fix that.
>
> 2014-11-24 23:07 GMT+01:00 Rich Megginson <rmeggins at redhat.com 
> <mailto:rmeggins at redhat.com>>:
>
>     On 11/24/2014 08:19 AM, Bartek wrote:
>>     Hello
>>     I have an use case where particular search operations on the same
>>     data in 1.2.5 and 1.2.11 differ significantly.
>>     1.2.5 is on Centos 5.9 and 1.2.11 on Centos 5.11. I'm asking this
>>     as i'm in the middle of upgrade process and I come across this
>>     performance issue.
>>
>>     After feeding both versions with data from the same text dump,
>>     particular search operation takes 0.5s in 1.2.5 to complete
>>     whereas in 1.2.11 it takes 6s:
>>
>>     ldapsearch -D 'uid=root,ou=users,o=xxx' -x -b
>>     'uid=someuser,dc=domain,dc=pl,o=xxx' -s subtree -w pass
>>     '(objectClass=someObjectClass)'
>>
>>     There is a set of 40 acls at the dc=pl,o=xxx node and 9 more on
>>     dc=domain,dc=pl,o=xxx. The acl allowing 'uid=root,ou=users,o=xxx'
>>     to access everything is at o=xxx.
>>
>>     I did already manage to figure out that the more acis i remove
>>     the shorter the search operation is. However even with those aci
>>     in place, search on 1.2.5 returns significantly faster.
>>
>>     I would like to ask if there are any factors that would make
>>     search operations longer while jumping from 1.2.5 to 1.2.11?
>
>     Not that I know of.
>
>     You can rule out acis as the source of the performance issue by
>     using -D "cn=directory manager" as the bind dn.
>
>     Use logconv.pl <http://logconv.pl> to analyze your access logs for
>     common problems.
>
>>
>>     -- 
>>     Regards
>>     Bartek
>>
>>
>>     --
>>     389 users mailing list
>>     389-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
>>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>     --
>     389 users mailing list
>     389-users at lists.fedoraproject.org
>     <mailto:389-users at lists.fedoraproject.org>
>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20141126/c10c32d6/attachment.html>