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
Comment 2Dariusz Wojewódzki
2019-06-05 15:39:09 UTC
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