<div dir="ltr">Folks<div><br></div><div>I think we do not need to switch to nginx-only or consider any kind of war between nginx and apache adherents. Everyone should be able to use web-server he or she needs without being pinned to the unwanted one. It is like Postgres vs MySQL war. Why not support both?</div><div><br></div><div>May be someone does not need something that apache supports and nginx not and needs nginx features which apache does not support. Let's let our users decide what they want.</div><div><br></div><div>And the first step should be simple here - support for uwsgi. It will allow for usage of any web-server that can work with uwsgi. It will allow also us to check for the support of all apache-like bindings like SPNEGO or whatever and provide our users with enough info on making decisions. I did not personally test nginx modules for SAML and SPNEGO, but I am pretty confident about TLS/SSL parts of nginx. </div><div><br></div><div>Moreover, nginx will allow you to do things you cannot do with apache, e.g. do smart load balancing, which may be crucial for high-loaded installations.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 4:12 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 09/17/2015 10:04 PM, Jim Rollenhagen
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
</pre>
<blockquote type="cite">
<pre>In the fuel project, we recently ran into a couple of issues with Apache2 +
mod_wsgi as we switched Keystone to run . Please see [1] and [2].
Looking deep into Apache2 issues specifically around "apache2ctl graceful"
and module loading/unloading and the hooks used by mod_wsgi [3]. I started
wondering if Apache2 + mod_wsgi is the "right" solution and if there was
something else better that people are already using.
One data point that keeps coming up is, all the CI jobs use Apache2 +
mod_wsgi so it must be the best solution....Is it? If not, what is?
</pre>
</blockquote>
<pre>Disclaimer: it's been a while since I've cared about performance with a
web server in front of a Python app.
IIRC, mod_wsgi was abandoned for a while, but I think it's being worked
on again. In general, I seem to remember it being thought of as a bit
old and crusty, but mostly working.</pre>
</blockquote>
<br></span>
I am not aware of that. It has been the workhorse of the
Python/wsgi world for a while, and we use it heavily.<span class=""><br>
<br>
<blockquote type="cite">
<pre>
At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]
and saw a significant performance increase. This was a Django app. uwsgi
is fairly straightforward to operate and comes loaded with a myriad of
options[1] to help folks make the most of it. I've played with Ironic
behind uwsgi and it seemed to work fine, though I haven't done any sort
of load testing. I'd encourage folks to give it a shot. :)</pre>
</blockquote>
<br></span>
Again, switching web servers is as likely to introduce as to solve
problems. If there are performance issues:<br>
<br>
1. Idenitfy what causes them<br>
2. Change configuration settings to deal with them<br>
3. Fix upstream bugs in the underlying system.<br>
<br>
<br>
Keystone is not about performance. Keystone is about security. The
cloud is designed to scale horizontally first. Before advocating
switching to a difference web server, make sure it supports the
technologies required.<br>
<br>
<br>
1. TLS at the latest level<br>
2. Kerberos/GSSAPI/SPNEGO<br>
3. X509 Client cert validation<br>
4. SAML<br>
<br>
OpenID connect would be a good one to add to the list; Its been
requested for a while.<br>
<br>
If Keystone is having performance issues, it is most likely at the
database layer, not the web server.<br>
<br>
<br>
<br>
"Programmers waste enormous amounts of time thinking about, or
worrying about, the speed of noncritical parts of their programs,
and these attempts at efficiency actually have a strong negative
impact when debugging and maintenance are considered. We <em>should</em>
forget about small efficiencies, say about 97% of the time: <strong>premature
optimization is the root of all evil.</strong> Yet we should not
pass up our opportunities in that critical 3%."
--Donald Knuth<span class=""><br>
<br>
<br>
<br>
<blockquote type="cite">
<pre>
Of course, uwsgi can also be ran behind Apache2, if you'd prefer.
gunicorn[2] is another good option that may be worth investigating; I
personally don't have any experience with it, but I seem to remember
hearing it has good eventlet support.
// jim
[0] <a href="https://uwsgi-docs.readthedocs.org/en/latest/" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/</a>
[1] <a href="https://uwsgi-docs.readthedocs.org/en/latest/Options.html" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/Options.html</a>
[2] <a href="http://gunicorn.org/" target="_blank">http://gunicorn.org/</a>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<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>
</pre>
</blockquote>
<br>
</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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>