gunicorn vs uwsgi

[Gour]

Hello,


I'm testing both gunicorn and uwsgi with web2py on my (production)
server with nginx acting as front-end/reverse-proxy. Deploying of
gunicorn is pure simplicity which I like (it reminds me on webpy) and I
can access web2py's admin via https, while having problem to do the same
with uwsgi.
│
My sites are and, after converting to web2py, will be small/low-traffic
and can raise to medium/medium-traffic in the future, while on my
hosting (ala webfaction) I have limit on the total memory used by apps
to 512MB and number of procs is 50.

Any idea which WSGI server behave better in such constrained
environment?

uWSGI certainly looks as very powerful, but maybe it is an overkill for
our needs and brings more trouble with configuration comparing it with
simple deployment via gunicorn?


Sincerely,
Gour

--
He is a perfect yogī who, by comparison to his own self,
sees the true equality of all beings, in both their
happiness and their distress, O Arjuna!

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Roberto De Ioris]

> Hello,
>
>
> I'm testing both gunicorn and uwsgi with web2py on my (production)
> server with nginx acting as front-end/reverse-proxy. Deploying of
> gunicorn is pure simplicity which I like (it reminds me on webpy) and I
> can access web2py's admin via https, while having problem to do the same
> with uwsgi.
> │
> My sites are and, after converting to web2py, will be small/low-traffic
> and can raise to medium/medium-traffic in the future, while on my
> hosting (ala webfaction) I have limit on the total memory used by apps
> to 512MB and number of procs is 50.
>
> Any idea which WSGI server behave better in such constrained
> environment?
>
> uWSGI certainly looks as very powerful, but maybe it is an overkill for
> our needs and brings more trouble with configuration comparing it with
> simple deployment via gunicorn?
>
>

While the "complexity" of uWSGI in latest times is questionable
(documentation improved a lot and the quickstart introduce to basically
everything you need), i always suggest newcomers to go pure-python
(rocket, gunicorn, flup...) as compilation can be a problem sometimes.

The problem is that once you start placing apps in constrained
environments, you will soon start to face low-level problems (dealing with
rss, address space, monitoring), something uWSGI is optimized for (for
example you can tell it to reboot after a memory limit is reached and so
on)

In addition to this uWSGI uses lot less memory and supports threading that
when you have few resources is a good approach for increasing concurrency.

The "overkill" definition is really funny (you are not the first person
saying it) becase generally uWSGI has hundreds more features than
"competitors" but it is the one consuming less resources :)

And just as a note (from the web2py directory, after having copied
wsgihandler.py from the handlers directory):

gunicorn --bind :9090 wsgihandler

uwsgi --http-socket :9090 --wsgi wsgihandler

is it so different ;) ?

--
Roberto De Ioris
http://unbit.it

[Niphlod]

+1: I really don't see the issue with uwsgi configs .

[Gour]

On Wed, 2 Oct 2013 15:16:23 +0200
"Roberto De Ioris" <rob...@unbit.it> wrote:

> While the "complexity" of uWSGI in latest times is questionable
> (documentation improved a lot and the quickstart introduce to
> basically everything you need), i always suggest newcomers to go
> pure-python (rocket, gunicorn, flup...) as compilation can be a
> problem sometimes.

Compilation is not the problem here 'cause I installed it via pip on my
hosting server without any problem.

> The problem is that once you start placing apps in constrained
> environments, you will soon start to face low-level problems (dealing
> with rss, address space, monitoring), something uWSGI is optimized
> for (for example you can tell it to reboot after a memory limit is
> reached and so on)

Hmm, that's good.

> In addition to this uWSGI uses lot less memory and supports threading
> that when you have few resources is a good approach for increasing
> concurrency.

Another 'pro'..

> The "overkill" definition is really funny (you are not the first
> person saying it) becase generally uWSGI has hundreds more features
> than "competitors" but it is the one consuming less resources :)

Well, I was mostly thinking if/whether uWSGI's power/advantage is
becoming more obvious when serving big web sites with *LOT* of traffic
where one wants to squueze last drop of performance.

> And just as a note (from the web2py directory, after having copied
> wsgihandler.py from the handlers directory):

I did that.

> gunicorn --bind :9090 wsgihandler

I did run gunicorn with:

python anyserver.py -p localport -s gunicorn

and I was able to access my web site at: http://tld/ without any further
port fiddling considering that nginx front-end is sending request to
127.0.0.1:localport, as well as web2py's adming interface via
https://tld/ by having previously saved with save_password call.

> uwsgi --http-socket :9090 --wsgi wsgihandler

Otoh, I was able to use uWSGI in the same configuration with:

[uwsgi]
http-socket = :localport
chdir = /home/some_path/virtualenvs/web2py/web2py
module = wsgihandler
master = true
processes = 4
venv = /home/some_path//virtualenvs/web2py


and running:

uwsgi uwsgi.ini

but could not accomplish same thing trying to access admin interface via
https?

> is it so different ;) ?

Well, *in theory* is quite close, but in practice it was huge difference
for me. :-)


Sincerely,
Gour

--
It is far better to discharge one's prescribed duties, even though
faultily, than another's duties perfectly. Destruction in the course
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.

[Roberto De Ioris]

>
> Well, I was mostly thinking if/whether uWSGI's power/advantage is
> becoming more obvious when serving big web sites with *LOT* of traffic
> where one wants to squueze last drop of performance.

The problem is that when you are just learning, the first objective is
getting things done, you are generally not interested in problems you do
not even immagine will arise (soon or later)

This is why projects like uWSGI, Passenger or the big J2EE application
servers seems "overpowered" to beginners (or to super-lucky people that
never had problems with webapps :)

It is not (only) a matter of performance, from a sysadmin point of view
things are different, that is why i removed "developer-friendly" from the
uWSGI front-page :P

>
>
> python anyserver.py -p localport -s gunicorn
>

wait wait, you are talking about anyserver.py, it is a cool script
included in web2py for simplified deployments, you cannot really say you
have tried gunicorn and its true power :)

regarding the https problem, well, if the password file is correct it
should works transparently (uWSGI honour the X-Forwarded-SSL header sent
by the webfaction proxy).

[Gour]

On Wed, 2 Oct 2013 17:32:46 +0200

"Roberto De Ioris" <rob...@unbit.it> wrote:

>

> The problem is that when you are just learning, the first objective is
> getting things done, you are generally not interested in problems you
> do not even immagine will arise (soon or later)

Correct.

> It is not (only) a matter of performance, from a sysadmin point of
> view things are different, that is why i removed "developer-friendly"
> from the uWSGI front-page :P

:-)

> wait wait, you are talking about anyserver.py, it is a cool script
> included in web2py for simplified deployments, you cannot really say
> you have tried gunicorn and its true power :)

I never said I did, but it served 'getting things done' objective. ;)

> regarding the https problem, well, if the password file is correct it
> should works transparently (uWSGI honour the X-Forwarded-SSL header
> sent by the webfaction proxy).

First, I'm not on webfaction, but on something similar to it and it does
not work with uWSGI, while it works with gunicorn.


Sincerely,
Gour

--
One who is not disturbed in mind even amidst the threefold
miseries or elated when there is happiness, and who is free
from attachment, fear and anger, is called a sage of steady mind.

[Roberto De Ioris]

>
>> regarding the https problem, well, if the password file is correct it
>> should works transparently (uWSGI honour the X-Forwarded-SSL header
>> sent by the webfaction proxy).
>
> First, I'm not on webfaction, but on something similar to it and it does
> not work with uWSGI, while it works with gunicorn.
>
>

And don't you think it would be better to understand why ?

Maybe it is an easy thing, maybe it is something "isp-specific" that would
be great to address.

I am not forcing you to use uWSGI (sorry if i gave you such idea) but as
you are a developer i suspect when a customer simply says "does not work"
without context you became a fury :) In addition to this, this is open
source, collaboration is what makes it great (and better)

[Gour]

On Thu, 3 Oct 2013 06:24:09 +0200

"Roberto De Ioris" <rob...@unbit.it> wrote:

> And don't you think it would be better to understand why ?

Sure, I just said it did not work out-of-the-box as with gunicorn.

> Maybe it is an easy thing, maybe it is something "isp-specific" that
> would be great to address.

I'll investigate further.

> I am not forcing you to use uWSGI (sorry if i gave you such idea)

Nope, np.

> but as you are a developer i suspect when a customer simply says "does
> not work" without context you became a fury :)

Well, I didn't mean to troubleshoot uwsgi problem here and I apologize
seeing that I didn't provide details about my 'https' problem in #uwsgi
either. :-(


Sincerely,
Gour

--
The senses are so strong and impetuous, O Arjuna,
that they forcibly carry away the mind even of a man
of discrimination who is endeavoring to control them.