So in any case i am using 20 processes and 20 threads to have optimal utilization. I did try with 50 50 values too for apache and the utilization spikes a bit high but its fine for load test. Utilization do touch around 40% for 20 20 values of processes and threads.I am running it on BM with 128gb memory.I am spinning 100 concurrent users. Rps is bit killing as create token does sign tokeb <span></span>operation too which consumes some time.<div><br></div><div>Regards,</div><div>Ali<br><br>On Wednesday, December 9, 2015, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Wednesday, December 9, 2015, Ginwala, Aliasgar <<a href="javascript:_e(%7B%7D,'cvml','aginwala@ebay.com');" target="_blank">aginwala@ebay.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Hi Dolph/team:</div>
<div> </div>
<div>As requested I have outlined most of the files and configs to give more clear picture @ <a href="https://gist.github.com/noah8713/7d5554d78b60cd9a4999" target="_blank">https://gist.github.com/noah8713/7d5554d78b60cd9a4999</a>:</div></div></div></blockquote><div><br></div>The number of threads per API your config files show range from 20 to 10,000<font size="2"><span style="background-color:rgba(255,255,255,0)"> (processes * threads)</span></font>. On one end, your server might be idling during the benchmark. On the other end, you're probably exhausting the server's memory during the benchmark run. So, absolutely nothing about this benchmark appears to be fair.<br><div><br></div><div>What is the maximum number of concurrent users you're spinning up to in locust? (not the spawn rate)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>
<div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">* keystone.conf   —uploaded</div>
<div class="gmail_extra">* distro used for testing, in case they override the project's defaults  —mentioned</div>
<div class="gmail_extra">* all nginx config files —uploaded nginx-keystone.conf<br>
</div>
<div class="gmail_extra">* all uwsgi config files —keystone-main.ini, keystone-admin.ini and upstart file</div>
<div class="gmail_extra">* apache config, including virtual hosts and mods —apache-keystone.conf and python files (common for nginx)</div>
<div class="gmail_extra">* your test client and it's configuration —mentioned</div>
<div class="gmail_extra">* server & client architecture, and at least some idea of what lies in between (networking, etc)  —briefly outlined </div>
<div class="gmail_extra">* whatever else I'm forgetting —feel free to add in the comments</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>Ali</div>
<div>
<div></div>
</div>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:12pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Dolph Mathews <<a>dolph.mathews@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a>openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, December 9, 2015 at 5:42 AM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a>openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">Benchmarks always appreciated!</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">But, these types of benchmarks are *entirely* useless unless you can provide the exact configuration you used for each scenario so that others can scrutinize the test method and reproduce your results. So, off the top of my head, I'm
 looking for:</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">* keystone.conf</div>
<div class="gmail_extra">* distro used for testing, in case they override the project's defaults</div>
<div class="gmail_extra">* all nginx config files<br>
</div>
<div class="gmail_extra">* all uwsgi config files</div>
<div class="gmail_extra">* apache config, including virtual hosts and mods</div>
<div class="gmail_extra">* your test client and it's configuration</div>
<div class="gmail_extra">* server & client architecture, and at least some idea of what lies in between (networking, etc)</div>
<div class="gmail_extra">* whatever else I'm forgetting</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">A mailing list is probably not the best method to provide anything other than a summary; so I'd suggest publishing the details in a gist, blog post, or both.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">And to comment on the results themselves: you shouldn't be seeing that big of a performance gap between httpd and everything else; something is fundamentally different about that configuration. These are just web servers, after all.
 Choosing between them should not be a matter of performance, but it should be a choice of documentation, licensing, community, operability, supportability, reliability, etc. Performance should be relatively similar, and thus a much lower priority in making
 your selection.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 8, 2015 at 10:09 PM, Ginwala, Aliasgar <span dir="ltr">
<<a>aginwala@ebay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<span>
<div><br>
</div>
<div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div><span style="color:rgb(34,34,34);font-family:'Times New Roman'">Hi All:</span></div>
</div>
</div>
<span>
<div>
<div style="word-wrap:break-word"><span>
<div>
<div style="color:rgb(34,34,34)"><font face="Times New Roman"><br>
</font></div>
<span style="background-color:rgb(255,255,255)"><font face="Times New Roman"><font color="#222222">Just to inform Steve and all the folks who brought up this talk ;We did some benchmarking using wsgi, apache and nginx for keystone with mysql as token backend
 and we got following results on Juno version. Hence I am just giving you brief highlight about the results we got.</font></font></span>
<div style="color:rgb(34,34,34)"><font face="Times New Roman"><br>
</font></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman">spawning 100 users per sec for create token, below are the results:</font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman"><br>
</font></span></div>
<div><font face="Times New Roman"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><b>Using nginx with uwsgi: </b></span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="background-color:rgb(245,245,245)"><font color="#333333"><span style="line-height:20px">rps
<b>32</b>    —(reqests/sec)</span></font></span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">median time ~ 3.3 sec </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">no of processes 20 </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><b>using apache </b></span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">rps <b>75</b> </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">median time ~ 1.3 sec </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">avg time - 1.5 sec </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">no of processes 20 </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><b>using wsgi </b></span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">rps
<b>28</b> </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">median time ~ 3.4 </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">avg 3.5 </span><br style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">
<span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)">no of processes 20 </span><br>
</font></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman"><br>
</font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman"><br>
</font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman">We are planning to switch to apache since we are not seeing good results using nginx with uwsgi. May be some more
 added support is required for nginx performance.</font></span><span style="line-height:20px;color:rgb(51,51,51);font-family:'Times New Roman';background-color:rgb(245,245,245)">We did not encounter this auto restart issue in test yet and hence
 are open to more inputs.</span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman"><br>
</font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman">Any other suggestions are welcome too. Let us know in case of queries.</font></span></div>
</div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(245,245,245)"><font face="Times New Roman"><br>
</font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(242,242,242)"><font face="Times New Roman">Regards, </font></span></div>
<div style="color:rgb(34,34,34)"><span style="color:rgb(51,51,51);line-height:20px;background-color:rgb(238,238,238)"><font face="Times New Roman">Aliasgar</font></span></div>
</span><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<div>
<div>
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<div class="gmail_extra"><br>
<div>
<div>
<div class="gmail_quote">
<div>
<div>On 8 December 2015 at 07:53, Thomas Goirand <span dir="ltr"><<a>zigo@debian.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 12/01/2015 07:57 AM, Steve Martinelli wrote:<br>
> Trying to summarize here...<br>
><br>
> - There isn't much interest in keeping eventlet around.<br>
> - Folks are OK with running keystone in a WSGI server, but feel they are<br>
> constrained by Apache.<br>
> - uWSGI could help to support multiple web servers.<br>
><br>
> My opinion:<br>
><br>
> - Adding support for uWSGI definitely sounds like it's worth<br>
> investigating, but not achievable in this release (unless someone<br>
> already has something cooked up).<br>
> - I'm tempted to let eventlet stick around another release, since it's<br>
> causing pain on some of our operators.<br>
> - Other folks have managed to run keystone in a web server (and<br>
> hopefully not feel pain when doing so!), so it might be worth getting<br>
> technical details on just how it was accomplished. If we get an OK from<br>
> the operator community later on in mitaka, I'd still be OK with removing<br>
> eventlet, but I don't want to break folks.<br>
><br>
> stevemar<br>
><br>
> From: John Dewey <<a>john@dewey.ws</a>><br>
> 100% agree.<br>
><br>
> We should look at uwsgi as the reference architecture. Nginx/Apache/etc<br>
> should be interchangeable, and up to the operator which they choose to<br>
> use. Hell, with tcp load balancing now in opensource Nginx, I could get<br>
> rid of Apache and HAProxy by utilizing uwsgi.<br>
><br>
> John<br>
<br>
</div>
</div>
The main problem I see with running Keystone (or any other service) in a<br>
web server, is that *I* (as a package maintainer) will loose the control<br>
over when the service is started. Let me explain why that is important<br>
for me.<br>
<br>
In Debian, many services/daemons are run, then their API is used by the<br>
package. In the case of Keystone, for example, it is possible to ask,<br>
via Debconf, that Keystone registers itself in the service catalog. If<br>
we get Keystone within Apache, it becomes at least harder to do so.<br>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>I was going to leave this up to others to comment on here, but IMO - excellent. Anyone that is doing an even semi serious deployment of OpenStack is going to require puppet/chef/ansible or some form of orchestration layer for deployment. Even for test
 deployments it seems to me that it's crazy for this sort of functionality be handled from debconf. The deployers of the system are going to understand if they want to use eventlet or apache and should therefore understand what restarting apache on a system
 implies.<br>
 <br>
</div>
<span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other issue is that if all services are sharing the same web server,<br>
restarting the web server restarts all services. Or, said otherwise: if<br>
I need to change a configuration value of any of the services served by<br>
Apache, I will need to restart them all, which is very annoying: I very<br>
much prefer to just restart *ONE* service if I need.<br>
<br>
Also, something which we learned the hard way at Mirantis: it is *very*<br>
annoying that Apache restarts every Sunday morning by default in<br>
distributions like Ubuntu and Debian (I'm not sure for the other<br>
distros). No, the default config of logrotate and Apache can't be<br>
changed in distros just to satisfy OpenStack users: there's other users<br>
of Apache in these distros.<br>
</blockquote>
</span>
<div><br>
:O<br>
 <br>
</div>
<span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Then, yes, uWSGI becomes a nice option. I used it for the Barbican<br>
package, and it worked well. Though the uwsgi package in Debian isn't<br>
very well maintained, and multiple times, Barbican could have been<br>
removed from Debian testing because of RC bugs against uWSGI.<br>
<br>
So, all together, I'm a bit reluctant to see the Eventlet based servers<br>
going away. If it's done, then yes, I'll work around it. Though I'd<br>
prefer if it didn't.<br>
<br>
It is also my view that it's up to the deployers to decide how they want<br>
to implement things. For many small use cases, Eventlet performs well<br>
enough.<br>
<br>
Finally, one thing which I never understood: if Eventlet is bad as an<br>
HTTP server, can't we use anything else written in Python? Isn't it<br>
possible to write a decent HTTP server in Python? Why are we forced into<br>
just Eventlet for doing the job? I haven't searched around, but there<br>
must be loads of alternatives, no?<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<div>
<div></div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>So I'd be ok with keeping eventlet around until after we can figure out something for multiple virtual envs (i think you'd replace virtualenvs with containers) , but i don't think the packaging should have anything to do with this.<br>
 <br>
</div>
<span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a>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>
</div>
</div>
</blockquote>
</span></div>
<br>
</div>
</div>
</div>
</div>
<span><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></div>
<br>
</div>
</div>
</div>
</span></div>
</div>
</span></div>
</div>
</span></div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span>
</div>

</blockquote>
</blockquote></div>