[openstack-dev] [keystone] Keystone handling http requests synchronously

Jay Pipes jaypipes at gmail.com
Fri Mar 29 13:19:57 UTC 2013


On 03/28/2013 05:04 PM, Adam Young wrote:
> On 03/26/2013 01:34 PM, David Kranz wrote:
>> This is without memcache in auth_token. I was trying to find a way 
>> past https://bugs.launchpad.net/keystone/+bug/1020127
>> which I think I now have. I  would appreciate it if you could validate 
>> my comment at the end of that ticket. Here, I just thought that the 
>> keystone
>> throughput was very low. I know that swift should not be hitting it so 
>> hard. If you were referring to using memcache in the keystone server 
>> itself then
> You can use memcached as an alternate token  back end, but I have no 
> reason to thin it would perform any better than SQL.  It was broken 
> until fairly recently, too, so I suspect it is not used much in the wild.

We use the memcached token backend in production. Performance is
substantially better for us because we use synchronous replication for
the identity tables between availability zones and regions. Replicating
the token table, which was inserting records at around 200K+ a day on a
simple test environment, was slow. The insert/update/delete rate of the
user, tenant, role, credential, and user_tenant_membership tables was
orders of magnitude less than the token table, and replicating
cross-country to multiple availability zones for those tables had
perfectly acceptable performance. The tradeoff is that tokens are not
cross-AZ, but AFAICT for our users that's not a big deal.

Note that we had to turn off PKI because memcached token backend is
broken with PKI in Folsom (PKI token is not hashed prior to memcache key
generation, resulting in keys too big to use in memcache -- fixed in
Grizzly). We're looking forward to deploying Grizzly shortly and will
likely enable PKI which should result in even better performance since
the number of roundtrips to Keystone is reduced.

We also use the templated catalog backend in production because the
various clients have no idea how to work with multiple availability
zones in the same region and just pick the first endpoint for their
service type returned.

May not be suitable in all cases, but this works well for us.

Best,
-jay



More information about the OpenStack-dev mailing list