[Openstack] [OpenStack] [Keystone] Performance difference between ferret and uuid tokens

Steve Martinelli s.martinelli at gmail.com
Sat Dec 10 20:23:23 UTC 2016


On Sat, Dec 10, 2016 at 10:59 AM, Alexandr Porunov <
alexandr.porunov at gmail.com> wrote:

> Hello,
>
> I read a blog about performance comparison between fernet and uuid tokens.
> They said that fernet tokens is 30% faster for creation but 400% slower for
> validation. Is it true?
>
>
I assume you are reading Dolph's blog post [1], that data is based off of
the kilo branch, we've made some improvements to performance since then, he
should probably do a follow up post for how the same performance tests run
on Newton ;)

Token validation can be improved using caching, which we worked on in
Liberty, Mitaka and Newton (the latest Mitaka release (9.2.0) includes a
critical performance fix, it was not backported to Liberty). Revocation
events are still an issue for performance, but we've been addressing that
in Ocata. I don't think we'll be able to backport the fixes for poor
revocation performance though, unfortunately it goes against the backport
policy.


FWIW, Matt Fischer has 4 blog posts about using fernet tokens in production
[2], they are very detailed and performance oriented. I really recommend
reading them, it's great stuff.


[1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
[2] https://www.mattfischer.com/blog/?tag=fernet


stevemar



> I want to use Keystone for Swift. I will have many requests with the same
> tokens so I need faster validation than faster creation. I would use uuid
> tokens but fernet tokens give us very good pros (we don't need to use a
> database). So, I decided to cache all fernet tokens on the Swift Proxy side
> for 30 minutes. Will the performance be the same for checking tokens in a
> cache or fernet tokens will still be 400% slower?
>
> Sincerely,
> Alexandr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20161210/5bf7ddb8/attachment.html>


More information about the Openstack mailing list