fernet memcache performance regression

Bug #1590179 reported by Brant Knudson on 2016-06-07
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Henry Nash
Mitaka
High
Unassigned

Bug Description

Fernet token validation performance got worse in mitaka vs in liberty. This is because it's not using memcache to cache the token anymore.

Changed in keystone:
assignee: nobody → Henry Nash (henry-nash)
status: New → In Progress
Changed in keystone:
importance: Undecided → High

Reviewed: https://review.openstack.org/326234
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3
Submitter: Jenkins
Branch: master

commit 9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3
Author: Henry Nash <email address hidden>
Date: Tue Jun 7 06:34:21 2016 +0100

    Revert to caching fernet tokens the same way we do UUID

    In Liberty we used to cache the whole token at the provider manager
    validate token call. However, in Mitaka we changed this, for
    non-persistent tokens (e.g. fernet), to instead attempt to cache
    the individual components that make up the token. This change caused
    validating a fernet token to become 5 times slower than the same
    operation in Liberty (as well as UUID in both releases).

    This patches re-instates full-token caching for fernet. This should be
    considered somewhat of a bandaid to redress the performance
    degredation, while we work to restructure our token issuance
    and validation to simplify the multiple code paths.

    In terms of invalidation of such a cache, this change effectively
    reverts to the Liberty approach where anything logged to the
    revokation manager will still cause validaiton of the token to fail
    (this is checked for all token types). However, the alternate (and
    confusingly additonal) "direct" invalidation of the cache via
    the pesistance manager will, like in Liberty, not have any
    effect with cached fernet tokens. As far as I can tell, all
    situations where we currently want a token revoked will send
    this information to both the revoke and persistance managers,
    hence this change should not result in any tokens remaining
    valid when they shouldn't.

    Closes-Bug: #1590179
    Change-Id: I80371746735edac075eec9986e89b54b66bc47cb

Changed in keystone:
status: In Progress → Fix Released
Brant Knudson (blk-u) on 2016-06-08
tags: added: mitaka-backport-potential

Reviewed: https://review.openstack.org/327381
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a878664f5dbf08626a796e8cfa6fac88cb9e256a
Submitter: Jenkins
Branch: stable/mitaka

commit a878664f5dbf08626a796e8cfa6fac88cb9e256a
Author: Henry Nash <email address hidden>
Date: Tue Jun 7 06:34:21 2016 +0100

    Revert to caching fernet tokens the same way we do UUID

    In Liberty we used to cache the whole token at the provider manager
    validate token call. However, in Mitaka we changed this, for
    non-persistent tokens (e.g. fernet), to instead attempt to cache
    the individual components that make up the token. This change caused
    validating a fernet token to become 5 times slower than the same
    operation in Liberty (as well as UUID in both releases).

    This patches re-instates full-token caching for fernet. This should be
    considered somewhat of a bandaid to redress the performance
    degredation, while we work to restructure our token issuance
    and validation to simplify the multiple code paths.

    In terms of invalidation of such a cache, this change effectively
    reverts to the Liberty approach where anything logged to the
    revokation manager will still cause validaiton of the token to fail
    (this is checked for all token types). However, the alternate (and
    confusingly additonal) "direct" invalidation of the cache via
    the pesistance manager will, like in Liberty, not have any
    effect with cached fernet tokens. As far as I can tell, all
    situations where we currently want a token revoked will send
    this information to both the revoke and persistance managers,
    hence this change should not result in any tokens remaining
    valid when they shouldn't.

    Closes-Bug: #1590179
    Change-Id: I80371746735edac075eec9986e89b54b66bc47cb
    (cherry picked from commit 9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3)

tags: added: in-stable-mitaka

This issue was fixed in the openstack/keystone 9.1.0 release.

Changed in keystone:
milestone: none → newton-2

This issue was fixed in the openstack/keystone 10.0.0.0b2 development milestone.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers