Open Stack

On Fri, Mar 29, 2013 at 8:19 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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.
>

P.S. really looking forward to hearing about the results of your switch to
PKI, given the size & architecture of your deployment


>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130329/f9abfcd0/attachment.html>