<div dir="ltr">Hi Gary,<div><br></div><div>A couple things come to mind right off the bat that I want to ensure are addressed:</div><div><br></div><div>1) Is caching enabled and is the memcache server in-fact accessible from the keystone process? Keystone is developed assuming you have caching enabled (we will be examining, during Train, making this a requirement instead of "strongly encouraged"). </div><div><br></div><div>2) Did you swap from uuid to Fernet between the deployments? Unfortunately, fernet is slower than UUID. We opted for fernet and taking the performance hit in light of the significantly better token management/maintenance for long-term running clouds. UUID token provider was removed as of rocky.</div><div><br></div><div>3) I am curious about the scenario you have built for rally: Is this scenario a real-world-ish scenario that you are doing on a regular basis? I want to be clear we are troubleshooting real-world(ish) scenarios and not synthetic problems that only occur in test scenarios; there are options to streamline test scenarios separately from real-world use-cases. Tell me more about the rally scenario. I also want to point out that I've been unable to get any real information from the attached files (they seem to be broken).</div><div><br></div><div>4) Is this running under mod_wsgi? uwsgi? is there a lot of other process space contention if under mod_wsgi in apache? (There isn't a lot of information about your configuration in the posed question), Configuration information, deployment in the container, etc helps us understand what is going on.</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 16, 2019 at 1:48 AM Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_707883612858682527gmail-m_8015047586800095103WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">Hi,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Over the last few weeks we have being doing performance tests on the Stein version and have seen a notable performance degradation. Further investigation showed that Keystone seems to be the bottleneck.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">An example of this is running a Rally test that creates a keystone tenant with users. We see that in Queens this takes 20 seconds to complete the whole iteration whilst Stein takes 30 seconds.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">We have done the following tests:</span><u></u><u></u></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="gmail-m_707883612858682527gmail-m_8015047586800095103MsoListParagraph" style="margin-left:0cm"><span style="font-size:11pt">Vanilla devstack Queens vs Steins</span><u></u><u></u></li><li class="gmail-m_707883612858682527gmail-m_8015047586800095103MsoListParagraph" style="margin-left:0cm"><span style="font-size:11pt">In our Stein version e have swapped out the Keystone Stein container with the Keystone Queens container and the numbers are considerably better too (please
 note the same keystone configuration is used with regards to processes/threads etc.)</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span style="font-size:11pt">Are any folks familiar with what may cause this?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Are there any performance improvement suggestions or hints?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Thanks</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Gary<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
</div>
</div>

</blockquote></div>