1. What is the nature and description of the request? With a Default Deploy of director Keystone Caching is not enabled by Default,it seems from the keystone upstream docs, that using caching with fernet is recommended[1]. Although Fernet tokens do not need to be persisted, they should still be cached for optimal token validation performance. Running some quick rally tests it seems there is a benefit on enabling caching on the keystone nodes By Default without caching: +-------------------------------------------------------------------------------------------------------------------------------+ | Response Times (sec) | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ | Action | Min (sec) | Median (sec) | 90%ile (sec) | 95%ile (sec) | Max (sec) | Avg (sec) | Success | Count | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ | keystone_v3.fetch_token | 0.663 | 1.426 | 1.69 | 1.793 | 2.243 | 1.445 | 100.0% | 1024 | | keystone_v3.validate_token | 1.0 | 2.447 | 2.805 | 2.903 | 3.482 | 2.455 | 100.0% | 1024 | | total | 1.671 | 3.907 | 4.364 | 4.488 | 4.988 | 3.901 | 100.0% | 1024 | | -> duration | 1.671 | 3.907 | 4.364 | 4.488 | 4.988 | 3.901 | 100.0% | 1024 | | -> idle_duration | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 100.0% | 1024 | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ With caching added to the config: [cache] backend = dogpile.cache.memcached enabled = true memcache_servers = SERVER:11211,SERVER:11211,SERVER:11211 +-------------------------------------------------------------------------------------------------------------------------------+ | Response Times (sec) | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ | Action | Min (sec) | Median (sec) | 90%ile (sec) | 95%ile (sec) | Max (sec) | Avg (sec) | Success | Count | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ | keystone_v3.fetch_token | 0.099 | 0.37 | 0.523 | 0.597 | 1.874 | 0.409 | 100.0% | 1024 | | keystone_v3.validate_token | 0.137 | 0.523 | 0.612 | 0.647 | 0.885 | 0.524 | 100.0% | 1024 | | total | 0.237 | 0.899 | 1.069 | 1.144 | 2.469 | 0.933 | 100.0% | 1024 | | -> duration | 0.237 | 0.899 | 1.069 | 1.144 | 2.469 | 0.933 | 100.0% | 1024 | | -> idle_duration | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 100.0% | 1024 | +----------------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+ It could be useful performance wise to have caching enabled in keystone using the already running memcached services on the controllers. 2. Why does the customer need this? On a big deployment with many token request enabling cache can enhance the token request performance 3. Is there already an existing RFE upstream or in Red Hat Bugzilla? Not that I could find [1] ]https://docs.openstack.org/keystone/latest/admin/identity-caching-layer.html#caching-for-tokens-and-tokens-validation
Hi, There is a note in the upstream documentation [1] mentioning that the memory backend is not suitable for production environments. Does it apply only for dogpile.cache.memory or also for dogpile.cache.memcached ? It would be great to have RedHat official clarification and possibly configuration best practice documented for keystone caching with memcached backend. [1] https://docs.openstack.org/keystone/queens/admin/identity-caching-layer.html