Issue 7616

Title
Use uwsgi instead of default werkzeug
Priority
feature
Status
resolved
Nosy list
ced, josesalvador, resteve, reviewbot, roundup-bot
Assigned to
ced
Keywords
review

Created on 2018-08-10.17:19:32 by ced, last changed 37 months ago by roundup-bot.

Messages

New changeset 78c9e2d65062 by Cédric Krier in branch 'default':
Use uwsgi for 4.8 and 4.6 series
https://hg.tryton.org/tryton-docker/rev/78c9e2d65062
Author: [hidden] (josesalvador)
Date: 2018-08-12.09:00:51
>Indeed benchmark should not be the final word. It is always possible to find >other that shows different result:
>https://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-benchmarks.html
>https://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi

Totally agree but this examples are too outdated (2010 and 2012)

>Also the performance is not for me the most important criteria.
>I think I do not like with gunicorn is that it has options like gevent, >eventlet, tornado which requires extra dependencies. So it does not fit well in >a Docker image if we want to keep it minimal.

Again, totally agree.

Thanks ced
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-08-12.00:13:16
Indeed benchmark should not be the final word. It is always possible to find other that shows different result:
https://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-benchmarks.html
https://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi
Also the performance is not for me the most important criteria.
I think I do not like with gunicorn is that it has options like gevent, eventlet, tornado which requires extra dependencies. So it does not fit well in a Docker image if we want to keep it minimal.
Author: [hidden] (josesalvador)
Date: 2018-08-11.19:49:10
A little research I did a few months ago bring gunicorn to me 'cause a better performance and a more reduced set of options than uwsgi (this is the reason that "scares" me, uswgi has a lot (too many IMO) options to tune it).

Althoug a bit old, here is a "reasonable" benchmarch article FYI:

https://blog.appdynamics.com/engineering/a-performance-analysis-of-python-wsgi-servers-part-2/

Anyway, uwsgi is a good and safe bet.

I like your open attitude when you talk about possible future changes of wsgi server. So, for sure, we will bring the better option for tryton.

Summarizing, it LGTM.

Thanks you ced.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-08-11.10:58:05
Indeed I looked to those from https://wsgi.readthedocs.io/en/latest/servers.html which provides HTTP and that are known (at least by me :-))
So this limited the list to:

* µwsgi: easy to setup, enough options and benchmark shows it is one of the faster
* Gunicorn: it is definitely an alternative but benchmark shows it is a little bit solwer.
* mod_wsgi: it is harder to configure because it is Apache. For me, it is not possible to configure with command line option
* werkzeug: we already have it :-)
* CherryPy: it is a full framework so it is redundant. Also I'm not sure it is configurable with command line option or we have to create such script.

But if in the future an new server emerge which is better for us, I think we could change per series.
Author: [hidden] (josesalvador)
Date: 2018-08-11.10:30:31
Have you considered to eval another wsgi servers??

Including any wsgi server in official docker image can become it as the standard de facto for tryton.

Is uwsgi, in your opinion as tryton's leader, the wsgi server you would choose to expose tryton in production environment?

Or may be there is another alternative more equilibrated between easy setup and performance?
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-08-10.17:19:31
Since version 4.6, we can easily run trytond as a WSGI application.
The werkzeug documentation [1] does not recommend to run their server in production. So I think we should lead by example and run the Docker image with a production ready server.
I propose to use uwsgi as it seems to be fast with a good set of options to tune it.
uwsgi should be just the default CMD, user may still want to run trytond (or trytond-cron) and it should serve the same way as trytond.
Also I think we should use the http-socket [2] to allow to connect to it directly for debugging and it keep the same behavior for existing deployment. User who wants to use wsgi protocol could still append a "--socket" argument.
I think we should implement this on both 4.6 and 4.8 images.

[1] http://werkzeug.pocoo.org/docs/0.14/serving/
[2] https://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#http-sockets
History
Date User Action Args
2018-08-23 11:35:45roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg43035
2018-08-14 14:23:14reviewbotsetmessages: + msg42912
2018-08-14 11:23:08reviewbotsetmessages: + msg42904
2018-08-13 10:53:40reviewbotsetnosy: + reviewbot
messages: + msg42892
2018-08-13 10:42:47cedsetstatus: in-progress -> testing
reviews: 52441002
keyword: + review
2018-08-13 10:10:46restevesetnosy: + resteve
2018-08-12 09:00:51josesalvadorsetmessages: + msg42889
2018-08-12 00:13:16cedsetmessages: + msg42888
2018-08-11 19:49:10josesalvadorsetmessages: + msg42887
2018-08-11 10:58:06cedsetmessages: + msg42872

Showing 10 items. Show all history (warning: this could be VERY long)