Performance and scaling¶
Before you begin tuning Keystone for performance and scalability, you should first know that Keystone is just a two tier horizontally-scalable web application, and the most effective methods for scaling it are going to be the same as for any other similarly designed web application: give it more processes, more memory, scale horizontally, and load balance the result.
With that said, there are many opportunities for tuning the performance of Keystone, many of which are actually trade-offs between performance and security that you need to judge for yourself, and tune accordingly.
If you’re using a token provider that requires persistence (such as UUID, PKI,
or PKIZ, but not Fernet), then you MUST periodically run
token_flush to purge the database of expired tokens. If you don’t, then your
SQL server will eventually become bloated and performance will suffer.
These are all of the options in
keystone.conf that have a direct impact on
performance. See the help descriptions for these options for more specific
details on how and why you might want to tune these options for yourself.
[DEFAULT] crypt_strength: Reduce this number to increase performance, increase this number to make SQL managed password checking more secure.
[DEFAULT] max_project_tree_depth: Reduce this number to increase performance, increase this number to cater to more complicated hierarchical multitenancy use cases.
[DEFAULT] max_password_length: Reduce this number to increase performance, increase this number to allow for more secure passwords.
[cache] enable: Enable this option to increase performance, but you also need to configure other options in the
[cache]section to actually utilize caching.
[token] provider: All of our token provider options have been primarily driven by performance considerations. UUID and Fernet both require online validation (cacheable HTTP calls back to keystone to validate tokens), whereas PKI can be validated in a distributed fashion. Fernet has the highest scalability characteristics overall, but requires more work to validate, and therefore enabling caching (
[cache] enable) is absolutely critical.
[fernet] max_active_keys: If you’re using Fernet tokens, decrease this option to improve performance, increase this option to support more advanced key rotation strategies.
This configuration actually lives in the Paste pipelines of services consuming token validation from keystone (i.e.: nova, cinder, swift, etc.).
cache: When keystone’s auth_token middleware is deployed with a swift cache, use this option to have auth_token middleware share a caching backend with swift. Otherwise, use the
memcached_servers: Set this option to share a cache across
token_cache_time: Increase this option to improve performance, decrease this option to respond to token revocation events more quickly (thereby increasing security).
revocation_cache_time: Increase this option to improve performance, decrease this option to respond to token revocation events more quickly (thereby increasing security).
memcache_security_strategy: Do not set this option to improve performance, but set it to improve security where you’re sharing memcached with other processes.
include_service_catalog: Disable this option to improve performance, if the protected service does not require a service catalog.
check_revocations_for_cached: Leave this option disabled to improve performance, but enable it if you’re using PKI tokens.
hash_algorithms: If you’re using PKI tokens, then use a high performance hash algorithm to improve performance, or choose a more rigorous hash algorithm to improve security. This option is ignored for other token formats.