<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 29, 2013 at 8:19 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/28/2013 05:04 PM, Adam Young wrote:<br>
> On 03/26/2013 01:34 PM, David Kranz wrote:<br>
>> This is without memcache in auth_token. I was trying to find a way<br>
>> past <a href="https://bugs.launchpad.net/keystone/+bug/1020127" target="_blank">https://bugs.launchpad.net/keystone/+bug/1020127</a><br>
>> which I think I now have. I  would appreciate it if you could validate<br>
>> my comment at the end of that ticket. Here, I just thought that the<br>
>> keystone<br>
>> throughput was very low. I know that swift should not be hitting it so<br>
>> hard. If you were referring to using memcache in the keystone server<br>
>> itself then<br>
> You can use memcached as an alternate token  back end, but I have no<br>
> reason to thin it would perform any better than SQL.  It was broken<br>
> until fairly recently, too, so I suspect it is not used much in the wild.<br>
<br>
</div>We use the memcached token backend in production. Performance is<br>
substantially better for us because we use synchronous replication for<br>
the identity tables between availability zones and regions. Replicating<br>
the token table, which was inserting records at around 200K+ a day on a<br>
simple test environment, was slow. The insert/update/delete rate of the<br>
user, tenant, role, credential, and user_tenant_membership tables was<br>
orders of magnitude less than the token table, and replicating<br>
cross-country to multiple availability zones for those tables had<br>
perfectly acceptable performance. The tradeoff is that tokens are not<br>
cross-AZ, but AFAICT for our users that's not a big deal.<br>
<br>
Note that we had to turn off PKI because memcached token backend is<br>
broken with PKI in Folsom (PKI token is not hashed prior to memcache key<br>
generation, resulting in keys too big to use in memcache -- fixed in<br>
Grizzly). We're looking forward to deploying Grizzly shortly and will<br>
likely enable PKI which should result in even better performance since<br>
the number of roundtrips to Keystone is reduced.<br></blockquote><div><br></div><div style>P.S. really looking forward to hearing about the results of your switch to PKI, given the size & architecture of your deployment</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We also use the templated catalog backend in production because the<br>
various clients have no idea how to work with multiple availability<br>
zones in the same region and just pick the first endpoint for their<br>
service type returned.<br>
<br>
May not be suitable in all cases, but this works well for us.<br>
<br>
Best,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>