[openstack-dev] Apache2 vs uWSGI vs ...

Alexander Makarov amakarov at mirantis.com
Fri Sep 18 14:28:39 UTC 2015


Please consider that we use some apache mods - does
nginx/uwsgi/gunicorn have oauth, shibboleth & openid support?

On Fri, Sep 18, 2015 at 4:54 PM, Vladimir Kuklin <vkuklin at mirantis.com> wrote:
> Folks
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
>
> On Fri, Sep 18, 2015 at 4:12 PM, 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
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuklin at mirantis.com
>
> __________________________________________________________________________
> 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
>



-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP



More information about the OpenStack-dev mailing list