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 怎么也有两万，我用不到那么快，但是你也别慢的太夸张啊。。。。本地延迟这么高，干点啥畏首畏尾。。。。

是我哪里配置错了吗？

经过带佬们回复补充，测了一下生产环境各种引擎的性能（单进程 rps ）。

gevent 1500

meinheld 2800

pypy3 + gevent 4200

感觉总的来说非常 py engine 界的扛把子非常尴尬啊，新特性 JIT+原生异步性能直追 node，但最广泛的生态还在坚持着老掉牙的性能，甚至低了一个数量级.....越来越唏嘘当初 py2 封流的时候 guido 真的应该加入一个异步库，哪怕是一个未确定 api 的框架，后续 2.8 完善也好。py 的 web 服务生态到今天一定是完全另一翻天地。

[black11black]

Running 10s test @ http://127.0.0.1:8080
16 threads and 500 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.53ms 149.08ms 1.74s 95.35%
Req/Sec 529.59 279.84 1.80k 68.10%
77017 requests in 10.03s, 16.89MB read
Socket errors: connect 0, read 0, write 0, timeout 20
Requests/sec: 7677.28
Transfer/sec: 1.68MB


Running 10s test @ http://127.0.0.1:8080
16 threads and 500 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 140.74ms 187.12ms 1.75s 88.36%
Req/Sec 104.58 98.50 336.00 74.31%
8123 requests in 10.22s, 1.78MB read
Socket errors: connect 0, read 0, write 0, timeout 10
Requests/sec: 794.46
Transfer/sec: 178.44KB

[assad]

上个 Swoole

[black11black]

@assad ？？？？？？？

[yzongyue]

我猜单线程比较慢的原因是 gunicorn 默认 syncworker，这时候请求一个处理完了才会处理下一个，并发太高了大部分时间都在排队
可以考虑把 worker 改成 gevent or meinheld

[Qzier]

搭配 meinheld 能快不少。

[black11black]

@yzongyue 我接触异步已经是 py3.4 以后的事了，一直是原生异步党，一直对猴子补丁观感不好，能不用尽量不用....不过好像 django 也没啥别的可用的，用 gevent 以后单线程 1500qps，fork 模式 10500qps，感觉勉强达到个 40 分水准吧。。。能用级别。
延迟还是居高不下，不是我说，linux 环境里本地 echo 还能跑到 2、300 毫秒的延迟实在是太夸张了。。。。facebook 以前怎么活下来的

[springz]

比 Laravel 好多了

[black11black]

@Qzier meinheld 确实比 gevent 快，单进程 2800，多进程 21424，勉强有个现代服务器的水准。。。。大佬知不知道这一套工具链 pypy 支不支持

[cabing]

但是处理不需要并发的业务撸的快。

[black11black]

@black11black pypy 测了一下，meinheld .so 载入错误跑不起，gevent，三分钟烤鸡后单线程 4275，多线程 11000，表现不如 cpython，多进程表现比较奇怪。

[yuyueMJ]

追求并发可以试下另一个 python 框架 falcon，自古两者难全。

[black11black]

@yuyueMJ 倒不是追求并发，没那么多高 PV 的业务，只是作为程序员天然地追求，性能稍微高一点，可以解锁很多适用场景。每秒五六百的 echo 数，流量几百 KB 基本属于完全不及格的水准。只是想学习前先了解一下 django 的性能如何。总的来说目前的看法是业务代码界的扛把子基本是性能的倒数第一，太尴尬了。

异步新框架性能也都不错，没什么难两全的，只是生态不好而已。

[whoami9894]

Django 和 flask 都是慢的真实，sanic 和 tornado 也好不到哪去。虽说是 io 密集操作，语言本身性能不是非常重要，但就是被隔壁 PHP7 吊起来打。原来看过有个 japronto 标榜的很强，基本都是 c 写的，但版本号还没上 0.2

[vicalloy]

异步 io 是为了解决 io 性能瓶颈的。我猜对于大多应用 Django 虽然慢，但瓶颈不在 io 这部分。
所以通常情况下不用这么介意这部分的性能。

[black11black]

@whoami9894 japronto 和 vibora 都是 demo 版本，写的时候异步 api 还没稳定，后来也没更了，sanic 和 tornado 不是一个量级的框架，没什么可讨论的

[black11black]

@vicalloy 对于绝大多数服务，你对 http 的本地 echo 的期望延迟应该在 1ms 左右，很难想象 100ms 你该如何构建应用。就像比如你搭建一些基于 TCP 的服务，单次 echo 在 500 微秒，你可以加一些控制协议实现整套流程在毫秒级别，反之如果单次 echo 很高，你加一些协议之后单次 echo 都要到秒级了，还怎么敢用

[ClericPy]

点进来以前以为会看到 channels 的...

[black11black]

@ClericPy 纯新，不熟悉 django。channels 好像以前听说过是个 django 版的异步项目？百度查了查怎么是关于 websocket 的

[luckyrayyy]

你试过 Java 的嘛……

[sagaxu]

django 空项目会装 7 个 middleware，先把它们去掉再测性能。另外可以试试 uwsgi，是不是比 gunicorn 更快。

[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 站点性能瓶颈基本上都是在数据库吧

[laike9m]

@ClericPy 可以加群一起吹 fastapi https://t.me/joinchat/Dm8lIVjvCo9_-6YZYLycEw

[o562dsRcFqYl375i]

@vicalloy 正解

[Vegetable]

世界上 90%的网站用 Django 写，性能都不会是瓶颈。也不知道你要用 Django 干什么会因为 900 的 qps 畏首畏尾。真正慢的 ORM 你还没用到呢就开始叫了吗
Django 去掉 middleware 之后 echo 的基本也就是一个空架子，和 flask 没什么区别。仔细了解工具的性能是好事，但是这种浮于表面的测试没有必要，回头和别人去黑都黑不到点子上。

[Kilerd]

gunicorn 没指定 gevent worker 就是 sync 模式，那肯定慢的啊。

[stoneabc]

你先把没用的 middleware 去掉。。
另外 Instagram 也用的 Django，几年前看他们方案是用的 uwsgi，性能上并没有太大问题。

[sujin190]

等你业务都已经做到堆机器 django 性能还是不够的时候，用不用 django 你已经无所谓了，所以 700 又咋滴很高了，这个世界也还没几个需要用的 700 每秒呢，大多数情况下相比运行性能业务性能更重要

[sprite82]

@Vegetable 世界上 90%的网站用 Django 写?大哥，能说下数据哪里来的吗

[Vegetable]

@sprite82
1.5 billion websites
Total number of Websites. There are over 1.5 billion websites on the world wide web today. Of these, less than 200 million are active.

随口说的，不过肯定是靠谱的，因为谷歌说 Active 的网站才 2 亿，占 15 亿的 13%...

[tabris17]

@black11black 不是 django 的异步版本，而是支持 ASGI （异步服务网关接口）

[tabris17]

@whoami9894 被隔壁 PHP7 吊起来打?拉倒吧，你一个全家桶框架跟 PHP 原生语言比个啥，同等级的 Laravel 一样慢出翔

[Hanggi]

@msg7086 不用 python 不就行了吗?

[wslzy007]

Golang 吧，各种 goweb 框架性能都不错，这里有性能测试数据供选型参考：www.jianshu.com/p/cc9417193b7f

[tutusolo]

Django makes it easier to build better Web apps more quickly and with less code.

这是他们官网对自己的定位 一个普通 web 网站不需要那么高的性能。

而且 py 的 web 框架 一般拿来做运维系统的和博客的居多

如果非要谈框架语言性能 可以尝试一下 go 追求极致的直接上 c++

[Cbdy]

看一下这个 benchmark
https://www.techempower.com/benchmarks

[limboMu]

这个问题的瓶颈不应该是出在 GIL 或者协程没办法抢占计算任务上吗

[Ansen]

追求性能的话，建议用 golang

py 的技能全加在敏捷上了

[gz911122]

@luckyrayyy 试过
vertx 打上 1w 轻轻松松 跟玩一样

[est]

django 只是个 web 框架。http 吞吐慢不慢跟框架有啥关系。。。

[luckyrayyy]

@gz911122 笨重的 spring boot+tomcat 呐？我怎么记得之前试的也很惨...不比 python 好多少

[tailf]

700 QPS 一天的 PV 就是 60480000，六千万都不够用吗？

[fuxkcsdn]

@Vegetable 你要说 90% 是 php 写的我还信，用 Django 写？真的是 章口就来 啊

[WenhaoWu]

Django 最主要的是它的 admim 吧，点点点就行太好用了

[freakxx]

@Vegetable #43
这就吹得有些过分了

[freakxx]

如果考虑并发的话，可以试下用 channel 走 ASGI 那一套， 搞多几个 worker。

[altboy]

@yzongyue 大佬说的对

[V69EX]

所以，现在网上用 python 写 web 服务的，听说不到 2%呀，多数还是 PHP……

[Vegetable]

@fuxkcsdn 我说了吗？再读一下好吗？实际上大部分网站是静态的好吗

[ytmsdy]

抬个杠，慢有怎么样？搞得你写出来的应用能到达 800QPS 一样的。

[Vegetable]

@freakxx 我只是认为网站的性能需求非常低罢了。互联网上的流量分配绝对比现实中的财富分配两极分化更严重。因此我认为完全没什么性能需求的网站超过 90%，这一观点和 Django 完全没什么关系。
Django3.0 已经支持 asgi 了，没必要再用 2.x 时代的方案了。

[yzongyue]

@altboy 大佬好 又见面了

[freakxx]

@Vegetable #69


> 互联网上的流量分配绝对比现实中的财富分配两极分化更严重。因此我认为完全没什么性能需求的网站超过 90%，这一观点和 Django 完全没什么关系。
黑人问号

> Django3.0 已经支持 asgi 了，没必要再用 2.x 时代的方案了。
...略下 channels 作者 Andrew Godwin 再来谈这句话吧。

[wuwukai007]

python 慢的问题，
java vs py 一亿次加运算，慢了好几个数量级
go vs py 计算斐波那契数列差了几个数量级，
项目经理：
这周做一个对爬取的万德债券基金做一个 OLS 回归计算，前台展示一下，
import requests
import numpy as np
```
xxxxxxxxxx
xxxxxxxxxx
return Response(xxx)
```
不妨做一个具体的业务逻辑，不要动不动就来个一亿次加运算，返回个 hello world。
Instagram 月活 10 亿用户，http 请求效率太低是不可能做到的，Instagram 的技术博客里有提到，目前使用 python
并没有成为性能瓶颈，相反是频繁迭代更新的利器。

[keepeye]

性能重要吗？重要！说不重要的到底是有多么财大气粗？别什么锅都往数据库什么的身上丢

[flypi]

动态语言写业务代码主要是容易变成💩山吧，做为无状态服务性能再怎么差都可以通过加机器解决，瓶颈还看下游的 DB

[LokiSharp]

@keepeye #73 如果是 Java 和 C++ 这种性能差别我觉得不重要（忽略内存
如果是 Python。。。这都差了几个数量级了。。。哈哈哈

[tlday]

@sprite82
@fuxkcsdn
@freakxx
#43 那楼没有说 90%的网站是用 Django 写的，你们需要重新认真读一下。逗号换个位置容易理解一点："世界上 90%的网站，用 Django 写性能都不会是瓶颈。"。但是逗号就算不换位置，也没有明显的歧义。看了半句就开始了还是有点...

[freakxx]

@tlday #76

我知道他意思不是说 90%是 django 写，所以我就说，这吹得有些过了。
即使我本身就是 drf 吹。

如果真的只是要杠的话，性能瓶颈是什么，这个才是杠的地方。

[justfortest]

@flypi 都一样，静态类型没文档也好不到哪去，还不是要一行行看，也不是所有参数都是有明确类型的。

[wuwukai007]

@justfortest 不是静态类型 传入参数类型不对，编译不通过的。。主要是这个

[johnsona]

Flask 不一样嘛，fastapi 我没用过，看楼上说比较现代，我要再把 flask 批判一番，flask 就很不现代，你看他那序列化反序列化写的，让我这个菜鸡怎么用。国内用 python 用到性能不够的转 go 了，这就是答案，不用的 django 中间件关掉，什么 session 啦，如果你要自己实现的话，模板啦

[jimrok]

多来几台机器不就好了，机器贵还是人贵。有些网站总共也没有几个并发，200ms 的响应时间用户体验也香呀。搞大型网站的，估计也轮不到 python，golang，java，scala，lua，c++都排着队等着搬砖呢。

[justfortest]

@wuwukai007 其实都差不多，在没有测试的基础上，编译过了代码也不代表没问题，只是后来人看的时候通过 ide 能方便跳转。

[black11black]

@flypi 这个总结有点道理

[sagaxu]

@justfortest 编译过了不保证正确，但是编译不过一定不正确，能过编译，至少能解决诸如变量未定义，拼写错误，参数传错类型，误删有人调用的方法等等低级错误。

[black11black]

@LokiSharp 差了几个数量级属于缺乏语言性能常识，即使极端情况下原生 cpython 解释与 c/c++的性能量级也不会需要“几”这个字来形容，不谈 py 部署多出来的 1%关键性能优化问题。

[sagaxu]

@black11black 极端情况下原生 cpython 能比 C++慢 100 倍甚至 1000 倍

[black11black]

@sagaxu 极端情况下一百倍正常，一千倍如果你见过，请列出证据，我反正是没见过。

[black11black]

@Cbdy 感谢，文章很有意思。不过这么一看 go 服务也并没比 py 快到跨量级的程度，基于 JIT 的 py+prefork 应该能做到整体五成到六成的水平，比较意外，我以为 go 应该再快一些

[windfarer]

不知道大佬们是做啥业务的有那么高的 qps

[sagaxu]

@black11black 极端情况差几万倍 http://people.duke.edu/~ccc14/sta-663-2016/B03_Optimization_Bakeoff.html

[LokiSharp]

@black11black 然而 Python 跑在 Pypy 和 CPython 上是两个 Python
pypy 甚至跑纯标准库写的东西都不一定能跑起来，更不用提各种要求 C 扩展的库

[gz911122]

@luckyrayyy tomcat 是不咋地
但是 spring boot webflux 表现就好了很多

[bnm965321]

1000qps 就能让你的网站每天由 1000 万 pv。

我觉得绝大多数网站很难达到这个水平吧？

[bnm965321]

@jimrok instagram，日活比 QQ 还高