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 <ayo...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
