Automatic toggle of virtual attributes handling


Overview


The server support virtual attributes in search requests. virtual attributes are supported in the search filter and also in the returned attributes. Virtual attributes are implemented via a list of registered service providers. This mechanism creates performance issues both in terms of CPU consumption and search throughput (contention). The reason is that the mechanism itself is complex and expensive. By default the server support virtual attributes and so reduce its throughput. This document propose a way to enable the support of virtual attribute only when it is necessary

Use cases


Major configuration options and enablement


The feature change the default value of the configuration attribute nsslapd-ignore-virtual-attrs to on. At startup, if the value is off (set by the DS admin) the server does nothing. If the value is on and if it exists virtual attribute definitions then the value is set to off

Design


Current implementation

Virtual attributes are implemented via private registering fonction slapi_vattrspi_regattr and slapi_vattrspi_register. So the only supported virtual attributes use the COS or ROLES plugins.

Roles plugin

The Roles plugin is enabled by default and registers a nsRole virtual attribute in its startup callback.

The values of the virtual attribute nsRole are taken from role definitions that are ldapsubentry with the objectclass nsRoleDefinition. So even if nsRole attribute is systematically registered, it has no impact unless it exists nsRoleDefinition entries.

Cos Plugin

The Cos plugin is enabled by default. It registers virtual attributes (cosAttribute) that are defined in cosSuperDefinition entries.

New implementation

The server will be configured to ignore by default virtual attributes (nsslapd-ignore-virtual-attrs: on).

If nsslapd-ignore-virtual-attrs: off (setting by the DS admin) do nothing, so do lookup for virtual attributes.

In slapi_vattrspi_regattr, if nsslapd-ignore-virtual-attrs: on and there is a registered attribute different than nsRole then toggle nsslapd-ignore-virtual-attrs: off. It logs the following message

INFO - slapi_vattrspi_regattr - Because employeeType is a new registered virtual attribute , nsslapd-ignore-virtual-attrs set to 'off'
Few second after startup (3sec), the server spawn a virtual-attribute check thread. That thread will do an internal search with the following filter *”(&(objectclass=ldapsubentry)( (objectclass=nsRoleDefinition)(objectclass=cosSuperDefinition)))”. If it retrieves one or more entries, then it toggles *nsslapd-ignore-virtual-attrs: off. Before doing the internal search, the thread exits if nsslapd-ignore-virtual-attrs: off.
INFO - vattr_check_thread - Found a role/cos definition in cn=FILTERROLEENGROLE,o=acivattr,dc=example,dc=com
INFO - vattr_check_thread - Because of virtual attribute definition nsslapd-ignore-virtual-attrs set to 'off'

Once the server is startup, new virtual attributes can be register. COS definition lead to call to slapi_vattrspi_regattr and the toggle of nsslapd-ignore-virtual-attrs is managed there. Role definition already have the nsRole virtual attribute registered, so it needs to be managed in roles_cache_trigger_update_role. When a new role definition is added the following message is logged in the error logs

INFO - roles_cache_trigger_update_role - Because of virtual attribute definition (role) then nsslapd-ignore-virtual-attrs set to 'off'

Tests

performance

Install the instance with sample entries, then add 20 entries like

dn: uid=demo[1..20]_user,ou=people,dc=example,dc=com
objectClass: top
objectClass: nsPerson
objectClass: nsAccount
objectClass: nsOrgPerson
objectClass: posixAccount
uid: demo[1..20]_user
cn: Demo User
displayName: Demo User
legalName: Demo User Name
uidNumber: 99998
gidNumber: 99998
homeDirectory: /var/empty
loginShell: /bin/false

Out of the box virtual attributes are disabled (default value nsslapd-ignore-virtual-attrs: on):

Enable support of virtual attribute

Reference


4678 and 1974236

Author


tbordaz@redhat.com

Last modified on 14 September 2021