<div dir="ltr">Reza,<div><br></div><div>afair the number of tokens that can be processed simultaneously by Keystone in reality is equal to the number of Keystone workers (either admin workers or public workers, depending on the user's nature). And this number defaults to the number of CPUs. So that is kind of default limitation, that may influence your testing.</div><div><br></div><div>Btw did you evaluate Rally for the Keystone CRUD benchmarking?</div><div><br></div><div>Cheers,</div><div>Dina</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 12:39 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Reza Bakhshayeshi's message of 2015-10-27 05:11:28 +0900:<br>
<span class="">> Hi all,<br>
><br>
> I've installed OpenStack Kilo (with help of official document) on a<br>
> physical HP server with following specs:<br>
><br>
> 2 Intel(R) Xeon(R) CPU E5-2695 v2 @ 2.40GHz each 12 physical core (totally<br>
> 48 threads)<br>
> and 128 GB of Ram<br>
><br>
> I'm going to benchmark keystone performance (with Apache JMeter) in order<br>
> to deploy OpenStack in production, but unfortunately I'm facing extremely<br>
> low performance.<br>
><br>
> 1000 simultaneously token creation requests took around 45 seconds. (WOW!)<br>
> By using memcached in keystone.conf (following configuration) and threading<br>
> Keystone processes to 48, response time decreased to 18 seconds, which is<br>
> still too high.<br>
><br>
<br>
</span>I'd agree that 56 tokens per second isn't very high. However, it<br>
also isn't all that terrible given that keystone is meant to be load<br>
balanced, and so you can at least just throw more boxes at it without<br>
any complicated solution at all.<br>
<br>
Of course, that's assuming you're running with Fernet tokens. With UUID,<br>
which is the default if you haven't changed it, then you're pounding those<br>
tokens into the database, and that means you need to tune your database<br>
service quite a bit and provide high performance I/O (you didn't mention<br>
the I/O system).<br>
<br>
So, first thing I'd recommend is to switch to Liberty, as it has had some<br>
performance fixes for sure. But I'd also recommend evaluating the Fernet<br>
token provider. You will see much higher CPU usage on token validations,<br>
because the caching bonuses you get with UUID tokens aren't as mature in<br>
Fernet even in Liberty, but you should still see an overall scalability<br>
win by not needing to scale out your database server for heavy writes.<br>
<span class=""><br>
> [cache]<br>
> enabled = True<br>
> config_prefix = cache.keystone<br>
> expiration_time = 300<br>
> backend = dogpile.cache.memcached<br>
> backend_argument = url:localhost:11211<br>
> use_key_mangler = True<br>
> debug_cache_backend = False<br>
><br>
> I also increased Mariadb, "max_connections" and Apache allowed open files<br>
> to 4096, but they didn't help much (2 seconds!)<br>
><br>
> Is it natural behavior? or we can optimize keystone performance more?<br>
> What are your suggestions?<br>
<br>
</span>I'm pretty focused on doing exactly that right now, but we will need to<br>
establish some baselines and try to make sure we have tools to maintain<br>
the performance long-term.<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><p style="font-size:small;margin:0px;font-family:Helvetica">Best regards,</p><p style="font-size:small;margin:0px;font-family:Helvetica">Dina Belova</p><p style="font-size:small;margin:0px;font-family:Helvetica">Senior Software Engineer</p><p style="font-size:small;margin:0px;font-family:Helvetica">Mirantis Inc.</p></div></div></div>
</div></div>