Open Stack

There is and has been desire to support uWSGI and other alternatives to mod_wsgi. There are a variety of operational reasons to consider uWSGI and/or gunicorn behind apache most notably to facilitate easier management of the processes independently of the webserver itself. With mod_wsgi the processes are directly tied to the apache server where as with uWSGI and gunicorn you can manage the various services independently and/or with differing VENVs more easily. 

There are potential other concerns that must be weighed when considering which method of deployment to use. I hope we have clear documentation within the next cycle (and possible choices for the gate) for utilizing uWSGI and/or gunicorn. 

--Morgan

Sent via mobile

> On Sep 18, 2015, at 06:12, Adam Young <ayoung at redhat.com> wrote:
> 
>> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:
>>> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
>>> 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?
>> 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.
> 
> I am not aware of that.  It has been the workhorse of the Python/wsgi world for a while, and we use it heavily.
> 
>> 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. :)
> 
> Again, switching web servers is as likely to introduce as to solve problems.  If there are performance issues:
> 
> 1.  Idenitfy what causes them
> 2.  Change configuration settings to deal with them
> 3.  Fix upstream bugs in the underlying system.
> 
> 
> 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.
> 
> 
> 1. TLS at the latest level
> 2. Kerberos/GSSAPI/SPNEGO
> 3. X509 Client cert validation
> 4. SAML
> 
> OpenID connect would be a good one to add to the list;  Its been requested for a while.
> 
> If Keystone is having performance issues, it is most likely at the database layer, not the web server.
> 
> 
> 
> "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 should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."   --Donald Knuth
>  
> 
> 
>> 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] https://uwsgi-docs.readthedocs.org/en/latest/
>> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
>> [2] http://gunicorn.org/
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150918/d2e71fe2/attachment.html>