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?
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 to analyze your access logs for common problems.
-- Regards Bartek
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Various system components need restricted access so using "cn=directory manager" is out of the question.
I set nsslapd-errorlog-level=128 (logs acl processing) to dig more into internals. Here's what I saw:
1.2.11
NSACLPlugin - #### conn=3 op=1 binddn="uid=root,ou=users,o=xxx" ............ cached allow by aci(7) ... NSACLPlugin - #### conn=3 op=1 binddn="uid=root,ou=users,o=xxx" .............cached allow by aci(7) ...
1.2.5 NSACLPlugin - #### conn=881 op=1 binddn="uid=root,ou=users,o=xxx" ...........cached allow by aci(7) ....... NSACLPlugin - #### conn=881 op=1 binddn="uid=root,ou=users,o=xxx" ..........cached context/parent allow .......
As you can see in 1.2.5, where search returns faster, for first returned entry there is "cached allow by aci(7)" whereas for every next there's "cached context/parent allow". In 1.2.11 however there is "cached allow by aci(7)" for every returned entry. Is this difference of any significance? Am i missing some king of caching in 1.2.11?
2014-11-24 23:07 GMT+01:00 Rich Megginson rmeggins@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 to analyze your access logs for common problems.
-- Regards Bartek
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@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 to analyze your access logs for common problems.
-- Regards Bartek
-- 389 users mailing list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@redhat.com mailto:rmeggins@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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org <mailto: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