Django 这性能，也慢的太夸张了.......

[black11black]

如题，前几天看论坛讨论帖都觉得 django 不错，学前先测了测性能。。

配置：（平台 ubuntu ）

django-admin startproject helloworld
# 编写一个 echo，访问 127.0.0.1:8080 回复"hello world"
gunicorn HelloWorld.wsgi -b 127.0.0.1:8080 -w 9

压测:

wrk -t16 -c500 -d10 http://127.0.0.1:8080

得到数据：

单进程 并发 794.46r/秒 ，平均延迟 140.74ms 九进程 并发 7700r/秒，平均延迟 28ms

虽然之前就想到 django 不会很快，毕竟 py 写服务性能也没那么重要，但是这也慢的太太太太太夸张了吧。。本地 echo 居然只有 700qps 的性能，本地 echo 延迟 0.1 秒，这。。。。。。。。。

对比一下 py 框架现在异步框架性能单线程 express 也能挑战一下的，就算 wsgi 跑的 flask，fork 的 rps 怎么也有两万，我用不到那么快，但是你也别慢的太夸张啊。。。。本地延迟这么高，干点啥畏首畏尾。。。。

是我哪里配置错了吗？

[ClericPy]

@black11black #18 Django 在 ASGI 方面也算是先驱了... 所以一直好奇, 那么肿的一个框架, 就算用上 ASGI, 但大部分业务代码也是纯 python 的话, 性能还是吃亏, 就想看看有没有什么体验过的介绍下

[ClericPy]

@black11black #18 另: 真指望 WSGI 下的 python 跑性能, falcon 算是比较硬了那一批了, 最近虽然也多了不少有 Cython 加成的新库, 但这个是真的又快又稳
最近因为很多代码写在协程里, 所以没怎么看过 WSGI 什么样子了, 毕竟: DRF 作者都去开发 uvicorn + starlette 了, 在 starlette 基础上另一个人搞的 fastapi, 最近用了半个月, 那体验无限接近人生第一次接触后端时候用 Bottle 的感觉, 闭着眼就写...

[sagaxu]

我用 ab 测了一下 uwsgi 跑这个 hello world，每核心 4500rps 以上，2 个进程下 rps 9400，响应平均 50ms。生产环境不会这么裸奔，前面会架个 nginx，开上 upstream 的 keepalive，减少建立 TCP 连接的开销。

[laike9m]

@ClericPy fastapi 确实好用

[msg7086]

性能好意味着很多工作要从框架和运行时转移到程序员的身上。

比如和手撸汇编相比，你会发现编译器直接优化的 C 代码“慢得太夸张了”。
我们用的 x265 核心是汇编写的，我刚测了一下，在没有 AVX2 的机器上，用汇编跑可以有 4fps，而用编译器优化的 C 代码跑只有 1.6fps。那为了这 1.5 倍的性能提升，程序员就得花下大把的时间去手写汇编，监控 CPU 状态，微调各个语句的顺序，来保证汇编代码的运行效率更高。

那大部分业务本来就不需要那么好的微操性能。能用缓存解决的，优先考虑缓存。能用更快的服务器解决的，优先换服务器。等服务器成本高到一定程度了才需要花几千几万美元的人工去撸成效率更高的语言。

> py 的 web 服务生态到今天一定是完全另一翻天地。

Python 的 Web 生态主要是源自死板统一的语法。死板的语法可以提高工程上的效率，降低人员流动时的风险。如果 Python 性能比现在高了一个数量级，那么势必这一个数量级所省下来的工作量就会转嫁到程序员身上。更多的加班，更多的 Bug，维护起来更难。不知道你喜不喜欢，反正我是不喜欢……

[ericls]

同样是 wsgi 性能差距不可能这么大的。 肯定是你哪里没搞对

[laminux29]

每种语言与配套环境，都有自己的优势与劣势。

你如果看中运行性能，应该用 C++。

用 Python，还上 Django，你看中的应该是开发效率，而不是运行性能。

[black11black]

@laminux29 你这是正确的废话，哪个蛋疼的用 c++写 web 业务

[black11black]

@sagaxu 带佬为啥 uwsgi 和我 gunicorn 部署效率差这么多？我默认配置单进程就 700

[LokiSharp]

用 Python 不要纠结性能，跑起来就好

[Leigg]

并发上 nginx

[loading]

python 名言：性能不够，机器来凑。

[laminux29]

@black11black

1.如果题主是小白，那就不是废话。

2.Web 业务分很多种，有些对性能有要求的，用 C++写很正常，只是这种情况不多罢了。

[janxin]

因为这就是真实...

当然也跟 Django 起手就是一堆东西给你配置好了，本身抽象过多带来的性能损耗有关系。

[a852695]

@ClericPy fastapi 的确很方便，该有的轮子都有了，只要按部就班写就好了，效率还不用担心

[hakono]

楼主可以和 laravel 比一下，没有对比就没有伤害

[ClericPy]

@laike9m #24
@a852695 #35
确实啊, 当年用 Bottle 的时候还没有 type hints, 一路基本上就是套装饰器然后返回 dict, 也不用我去拿 dict 包装 response
去年用 starlette 感觉一路很标准的中规中矩, 各方面设计都非常严格合理, 当时对 fastapi 的感觉就是一堆语法糖
真用上 fastapi 是今年, 这货的设计思路太美了, "真现代框架", 对 python 来说业务逻辑要思考的它大部分都简化了, 语法也省了很多

最喜欢的就是

通过类型注解自动做好类型转换, 毕竟前端 input 提交上来几乎就是字符串了, 被 pydantic 自动转对应类型 (int, Path, dict), 尤其是 pydantic + databases 操作数据库, 增删改查时候简直就是自带类型转换的轻量级 ORM
结合上面的操作, 以及提交 JSON 时候自动转对象, 写东西那叫舒服, 以前最头疼的类型验证替我兼容好了 int str 之类的互转, params 也是, 早前还觉得为这个丢性能不值得, 现在比什么都香, 让一个强类型语言做到类型的智能转换, 省了太多时间和代码了

PS: 昨晚上升级了下 mypy, 本来没报错的代码, 90% 全标红了... 最新版太严格了

[neoblackcap]

@black11black 你又要抽象好，又不愿意付出运行时的性能，又不愿意付出时间。这实在是很难满足你的需求。

要知道在 facebook 的 wangle 跟 folly 的加持下用 C++11 也很容易写出 CURD web 项目，绝对没有想象中的慢

[vicalloy]

由于 Django 默认启用了很多模块，因此测试前请确保把无关的模块都关了。根据我的测试，把不必要的东西去掉后性能差别很大。
Django 对 HTTP 请求的处理能力很弱，这样的测试，所有瓶颈都在 IO 部分，CPU 完全跑不满。等你把模板、数据库处理等功能加上后 IO 这部分的瓶颈就变的不那么明显。

Instagram 有在用 Django。虽然不知道 Instagram 具体做了哪些定制化，但至少在基础的 HTTP 请求处理上不会是明显的瓶颈。
程序员对性能有追求没有问题，但单纯的纠结在 HTTP 处理能力上没有多少意义。

DEBUG = False
ALLOWED_HOSTS = []
INSTALLED_APPS = []
MIDDLEWARE = []
ROOT_URLCONF = 'helloworld.urls'
TEMPLATES = []
WSGI_APPLICATION = 'helloworld.wsgi.application'
DATABASES = {}
AUTH_PASSWORD_VALIDATORS = []
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = False
USE_L10N = False
USE_TZ = False

[misaka19000]

性能不够堆机器啊，再说了现在的 web 站点性能瓶颈基本上都是在数据库吧