On 18/09/15 06:44 -0700, Morgan Fainberg wrote:
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.


+1

FWIW, Zaqar has always been shipped as a wsgi app and the container
the team has recommended ever since it was put in production for the
first time has been uWSGI. uWSGI is already used by Zaqar in the gate
but it's being installed independently.

Flavio


--Morgan

Sent via mobile

On Sep 18, 2015, at 06:12, Adam Young <[email protected]> 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: 
[email protected]?subject:unsubscribe
       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



   __________________________________________________________________________
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe: [email protected]?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco

Attachment: pgpDTPJKj5vGw.pgp
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to