* When using an LDAP backend for Keystone, the performance can be slow if there are
a large number of users using the cloud. This is due in large part to querying the
SQL database for the identity mapping information of each user in a separate transaction.
For example, an environment with 12,000 users will result in 12,000 sql queries to the
backend database in order to fulfill a user list request. This causes some admin
functions in Horizon UI to take several minutes, which often exceeds the WSGI and any
haproxy timeouts configured.
* This is fixed by backporting a series of patches which caches previously fetched identity
mapping information in a memcached instance and changes the logic to query all of the
user id mapping by the domain the id mapping is in. Additionally, the keystone-manage
command to sync the id mapping information with a backend database in an offline manner
is included to allow offline syncing of the data.
[Test Case]
* Install keystone using an ldap backend w/ large number of users.
* List user information: openstack user list --domain <domain_id>
* observe slow down
[Regression Potential]
* For Mitaka, the caching backends such as memcached or mongodb will likely see more
usage and an increased footprint due to additional data being cached. Caching the
identity mapping information is now standard since Newton and no major issues have
been seen coming from this.
* This code affects the identity mapping between keystone user and the ldap user
(essentially the bridge between the two). While it does not functionally alter the
information that is mapped (e.g. no difference in how the identity mapping is calculated),
it does alter a key code path for information regarding user identity mappings.
[Other Info]
* These patches have been run and tested in a staging environment to production and
have had exposure in the Mitaka path for approximately one month to show their stability.
[Impact]
* When using an LDAP backend for Keystone, the performance can be slow if there are
a large number of users using the cloud. This is due in large part to querying the
SQL database for the identity mapping information of each user in a separate transaction.
For example, an environment with 12,000 users will result in 12,000 sql queries to the
backend database in order to fulfill a user list request. This causes some admin
functions in Horizon UI to take several minutes, which often exceeds the WSGI and any
haproxy timeouts configured.
* This is fixed by backporting a series of patches which caches previously fetched identity
mapping information in a memcached instance and changes the logic to query all of the
user id mapping by the domain the id mapping is in. Additionally, the keystone-manage
command to sync the id mapping information with a backend database in an offline manner
is included to allow offline syncing of the data.
[Test Case]
* Install keystone using an ldap backend w/ large number of users.
* List user information: openstack user list --domain <domain_id>
* observe slow down
[Regression Potential]
* For Mitaka, the caching backends such as memcached or mongodb will likely see more
usage and an increased footprint due to additional data being cached. Caching the
identity mapping information is now standard since Newton and no major issues have
been seen coming from this.
* This code affects the identity mapping between keystone user and the ldap user
(essentially the bridge between the two). While it does not functionally alter the
information that is mapped (e.g. no difference in how the identity mapping is calculated),
it does alter a key code path for information regarding user identity mappings.
[Other Info]
* These patches have been run and tested in a staging environment to production and
have had exposure in the Mitaka path for approximately one month to show their stability.