It appears that you don't have caching enabled, then. Without enabling caching, Fernet performance is well known to be terrible, which would explain your benchmark results. If you run a similar benchmark with caching, I'd be eager to see the new configuration and benchmark results.
On Fri, Feb 17, 2017 at 8:16 AM 王玺源 <wangxiyuan1...@gmail.com> wrote: > Hi Dolph: > > We made the keystone.conf same with the example. > > [token] > > provider = fernet > > > > [fernet_tokens] //all configuration is default > > # > > # From keystone > > # > > > > # Directory containing Fernet token keys. (string value) > > #key_repository = /etc/keystone/fernet-keys/ > > > > # This controls how many keys are held in rotation by keystone-manage > > # fernet_rotate before they are discarded. The default value of 3 means > that > > # keystone will maintain one staged key, one primary key, and one secondary > > # key. Increasing this value means that additional secondary keys will be > kept > > # in the rotation. (integer value) > > # max_active_keys = 3 > Dolph Mathews <dolph.math...@gmail.com>于2017年2月17日 周五上午7:22写道： > > Thank you for the data and your test scripts! As Lance and Stanek already > alluded, Fernet performance is very sensitive to keystone's configuration. > Can your share your keystone.conf as well? > > I'll also be in Atlanta and would love to talk Fernet performance, even if > we don't have a formal time slot on the schedule. > > On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad <lbrags...@gmail.com> > wrote: > > In addition to what David said, have you played around with caching in > keystone [0]? After the initial implementation of fernet landed, we > attempted to make it the default token provider. We ended up reverting the > default back to uuid because we hit several issues. Around the Liberty and > Mitaka timeframe, we reworked the caching implementation to fix those > issues and improve overall performance of all token formats, especially > fernet. > > We have a few different performance perspectives available, too. Some were > run nearly 2 years ago [1] and some are run today [2]. Since the Newton > release, we've made drastic improvements to the overall structure of the > token provider [3] [4] [5]. At the very least, it should make understanding > keystone's approach to tokens easier. Maintaining out-of-tree token > providers should also be easier since we cleaned up a lot of the interfaces > that affect developers maintaining their own providers. > > We can try and set something up at the PTG. We are getting pretty tight > for time slots, but I'm sure we can find some time to work through the > issues you're seeing (also, feel free to hop into #openstack-keystone on > freenode if you want to visit prior to the PTG). > > > [0] > https://docs.openstack.org/developer/keystone/configuration.html#caching-layer > [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ > [2] https://github.com/lbragstad/keystone-performance > [3] > https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default > [4] > https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider > [5] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html > > On Wed, Feb 15, 2017 at 8:44 AM, David Stanek <dsta...@dstanek.com> wrote: > > On 15-Feb 18:16, 王玺源 wrote: > > Hello everyone, > > PKI/PKIZ token has been removed from keystone in Ocata. But recently > our > > production team did some test about PKI and Fernet token (With Keystone > > Mitaka). They found that in large-scale production environment, Fernet > > token's performance is not as good as PKI. Here is the test data: > > > > > https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM25NzZcdzPE0fvY/edit?usp=sharing > > This is nice to see. Thanks. > > > > > > From the data, we can see that: > > 1. In large-scale concurrency test, PKI is much faster than Fernet. > > 2. PKI token revoke can't immediately make the token invalid. So it has > the > > revoke issue. https://wiki.openstack.org/wiki/OSSN/OSSN-0062 > > > > But in our production team's opinion, the revoke issue is a small > problem, > > and can be avoided by some periphery ways. (More detail solution could be > > explained by them in the follow email). > > They think that the performance issue is the most important thing. Maybe > > you can see that in some production environment, performance is the first > > thing to be considered. > > I'd like to hear solutions to this if you have already come up with > them. This issue, however, isn't the only one that led us to remove PKI > tokens. > > > > > So here I'd like to ask you, especially the keystone experts: > > 1. Is there any chance to bring PKI/PKIZ back to Keystone? > > I would guess that, at least in the immediate future, we would not want > to put it back into keystone until someone can fix the issues. Also > ideally running the token provider in production. > > > > 2. Has Fernet token improved the performance during these releases? Or > any > > road map so that we can make sure Fernet is better than PKI in all side. > > Otherwise, I don't think that remove PKI in Ocata is the right way. Or > > even, we can keep the PKI token in Keystone for more one or two cycles, > > then remove it once Fernet is stable enough. > > 3. Since I'll be in Atalanta next week, if it is possible, I'd like to > > bring this topic to Keystone PTG. can I? > > Sure. We have a pretty packed calendar, but I'm sure you could steal a > few minutes somewhere. > > > > > > It is a real production problem and I really need your feedback. > > > > Have you tried playing with the crypt_strength[1]? If the slowness is > the crypto (which it was in the past) then you can tune it a little bit. > Another option might be to keep the same token flow and find a faster > method for hashing a token. > > 1. > http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n67 > > > -- > david stanek > web: https://dstanek.com > twitter: https://twitter.com/dstanek > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > -Dolph > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
