Python 项目部署, uwsgi 还是 gunicorn ? 或者其他选择

啊。。。gunicorn 不依赖 libev 了？


个人觉得 uWSGI >>>>> gunicorn 。

如果你嫌弃 uWSGI 安装麻烦请直接上二进制包 pip install pyuwsgi 。

Nginx unit

最大的坑就是，只有 windows 生产环境的时候 uwsgi 就没法部署了

gunicorn 性能差一点，但是可以用 py 文件写配置

@fub2020 用 apache 还是可以部署的，只是比较麻烦

可以参考一下 https://github.com/tiangolo 的 dockerfiles

日常 gunicorn，性能还行，win 的时候 gunicorn 也不行

感觉都差不多，静等大佬解释有啥区别

uWsgi 吧，装个依赖而已。。。
访问量没有到一定数量级的时候，性能问题忽略不计。
自己熟悉那个装那个吧。

新公司直接部署到容器上，然后用的 python main.py
不忍直视

@triangle111 flask 吧，遇到过好几个项目了，直接 python main.py

uwsgi 性能比 gunicorn 高不了多少，问题多了不少。比如配置，worker 之类的问题遇到了不少。

@xchaoinfo
为了简单可靠，还是 gunicorn 吧, 出活快, 容易维护.
为了性能... 就不要折腾 Python, 换 Go 吧.

tornado 套一下也行，变成纯 python 的

http_server = HTTPServer(WSGIContainer(app))

等 nginx + gunicorn 多 worker 都能成为瓶颈，你的项目起码市值破亿。

纯 WSGI server，uwsgi 比 gunicorn 高不了多少，gunicorn 还能换 worker 提升执行效率。uwsgi 关键在于它与 web server 的结合比较好，同时干了很多其他的事情，比如进程管理啥的。明白自己的需求再选择

@est uwsgi 在比较老的机器上遇到 c lib 依赖的坑, gunicorn 目前没有发现类似的问题.

Django 用以跑分的配置是 gunicorn+meinheld 。你应该就懂该用哪个了。

@abersheeran 感谢, 这个方案我也尝试下, 不知道兼容性如何

@fub2020 问一下 Windows 下生产环境部署有什么建议吗

supervisor 管理 gunicorn 进程啊

系统问题上 docker
性能问题上 Cython/uvloop/Django-channels (都特么 python 了还要什么性能, 直接水平扩容算了)
依赖问题用 pipenv/poetry/shiv/venv
守护问题用 systemd/airflow/azkaban/supervisor

现在一直在 asgi, 所以上面的东西都是我胡编的 :)

@sunhk25 waitress

python 性能问题最后再定位到部署上面，哪个熟悉用哪个，相同配置下的部署层面差别明显

@iConnect 他这个应该是后端瓶颈，不是配置瓶颈

@inframe 我同样也是 tornado 套 django，部署很方便，而且可以连同起很多服务，一个脚本就搞定

作为 ASGI 用户，每次看到 WSGI 们纠结 Windows 就觉得有 Uvicorn 真好，Waitress 到现在连个 SSL 都不支持，Uvicorn 功能已经做到快和 Gunicorn 齐平了。

@xchaoinfo 那是 pip install uwsgi 的坑啊。现在 pip install pyuwsgi 没坑。

新手就用 gunicorn

通过 supervisor 管理 gunicorn，提供启停管理服务。

@sunhk25 IIS+wfastcgi

@est #1 pre-fork：uwsgi 是初始化之后才 fork 的, gunicorn 是 fork 之后初始化 感觉这个就挺坑的。。

@di94sh 有啥坑的。。lazy-app 了解一下。

https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#preforking-vs-lazy-apps-vs-lazy

https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

很多人是被 uWSGi 的文档给夯退的。这个我承认。。。gunicorn 一页就能把所有参数给全的确很不错。但是 too simple 。。

@est 还有个最大的坑就是 uwsgi 的 http 实现极其不完善（甚至还有 http 和 http-socket 的区别） ，最好用 uwsgi 协议。如果用 HTTP，前面挂 nginx，不要直接对外或者挂在 ELB 后面

@timonwong http 的实现挺完善了。http-socket 是用来作为 nginx 的 upstream 的没啥问题啊。甚至还有 http11-socket 。


你要说 uWSGI 的不完善，怎么也比 gunicorn 的完善啊。。。

uwsgi 协议我现在觉得不香了。因为是一个请求一个连接。。太费 tcp 了。。

gunicorn 方式部署好像不兼容一些 pyhton 的 socket 工具

nginx + gunicorn

good comments, mark

flask + nginx + uwsgi 无法利用多核，uwsgi 配置：
callable=app
processes=4
threads=4
lazy-apps=true
哪位大佬 帮忙看看？