这是一个创建于 365 天前的主题，其中的信息可能已经有所发展或是发生改变。
有那么多高性能的 web 框架，为啥还是有不少人选择 django
 |
1
GTim 2024-02-02 08:46:08 +08:00
因为 99%的网站流量之低，根本轮不到拼性能的时候
|
 |
2
xuqiccr 2024-02-02 08:50:59 +08:00
我都用 Django 了我还在乎性能吗（不是），我都是用来做内部各种运维平台的，根本无所谓性能
|
 |
3
weaving 2024-02-02 09:00:54 +08:00
选择 Django 是因为能快速迭代我的需求，至于性能嘛，等流量来了再解决，实际上多数情况是没流量，我就要破产了😋
|
 |
4
echo1937 2024-02-02 09:02:55 +08:00  1
我们买车的时候也不是光盯着动力性能这一项啊。
|
 |
5
superrichman 2024-02-02 09:03:41 +08:00
高性能 ❎
性能过剩 ✅ |
 |
6
ljsh093 2024-02-02 09:06:05 +08:00
业务量没大到框架性能瓶颈、且开发真的很快
|
 |
7
cyrivlclth 2024-02-02 09:06:38 +08:00
做项目不是不计成本的，日活<2 ，你性能支持千万并发又咋样，该凉还是凉。早出活，早上线，跑出利润再说。有钱了，什么性能差之类的，再找人优化不就行了。
|
 |
8
amon 2024-02-02 09:10:50 +08:00 1
想明白这个问题，你就跳出了一个技术思维圈。
|
 |
9
ytmsdy 2024-02-02 09:20:40 +08:00
99%的项目都触及不到框架的性能瓶颈，就算达到了瓶颈也有很多其他手段来解决，如果其他手段上了，还继续触碰到瓶颈，那就不是单个程序员能搞定的事情了。
Django 这玩意儿主要是快，很多东西开箱即用，简单手快的，我一个小时就能高出一个用户登录，用户信息获取 API 。 |
 |
10
darkengine 2024-02-02 09:26:35 +08:00 1
因为这是个工程问题
|
 |
11
coolair 2024-02-02 09:31:46 +08:00
python 的其他 web 框架，很多第三方扩展都停止维护了，目前就 Django 的生态欣欣向荣。
|
 |
12
echo0x000001 2024-02-02 09:33:16 +08:00
热知识，django github 75k star ，spring boot 71k star.
|
 |
13
Vegetable 2024-02-02 09:38:13 +08:00 4
我司的主力服务使用的是 flask 古早版本，日活三万左右。使用普通 ECS 部署，我看了一下最近 24 小时的请求数量是 4 百万次，峰值很难达到 100req/s 。
这个水平的服务我们的 flask 这一层需要 100 个 worker ，分布在 4 ～ 5 个 ECS 上。切换成任何一个高性能的 web 框架，也仍然要保留至少两个实例。当前的服务器成本还比不上一个新手运维的工资，切换成别的框架，能节省的成本更是有限。 作为一个运行了多年的服务，让人干点正事儿，在熟悉的体系内工作，可能更划算 |
 |
14
june4 2024-02-02 09:58:55 +08:00
除非请求中间要同步调用外网非常慢的异步查询，否则同步和异步性能并没有区别
|
 |
15
Morriaty 2024-02-02 10:06:48 +08:00
@Vegetable 没玩过生产环境的 flask ，请问这里的 100 个 worker 是相当于 100 个 process 吗？相当于 1req/s/pro 这也太跌破我想象了🤣
|
 |
16
brom111 2024-02-02 10:19:06 +08:00
不是性能最强就是最好的。
盈利永远无限的高于技术 |
 |
17
gaogang 2024-02-02 10:20:06 +08:00
大部分项目活不到拼性能的时候
而且 django 也有方案可以实现异步 |
|
18
Vegetable 2024-02-02 10:35:40 +08:00
@Morriaty 我们确实是一个 worker 占用一个 process ，100 个 woker 就相当于 100 个进程。这个数量是留了不少冗余空间的，业务低峰时段是比较闲的
|
 |
19
locoz 2024-02-02 10:36:05 +08:00
没有那么多需要高性能的业务，绝大多数业务要的只是有个程序去辅助管理而已，最多也就把后台的自动化部分做得高性能点，面向用户的服务部分差不多就行了，哪个熟悉、方便就用哪个。
而且现在的 CPU 和内存都极其便宜，就算是用户量突然暴涨，靠硬堆进程数量也完全可以解决问题，大不了成本快超过性价比极限的时候再开始针对特定模块做重构都来得及。 |
 |
20
justplaymore 2024-02-02 10:38:39 +08:00
小电驴性能不如 F1 ，为什么还有这么多人用？
在能够满足需求的前提下，选择成本最小的，这就是权衡的核心思路。 |
 |
21
salmon5 2024-02-02 10:44:16 +08:00
django 的项目用户最多几千，并发几个
|
|
22
salmon5 2024-02-02 10:45:21 +08:00
自行车载人这么少，为什么都不用大巴车？
|
 |
23
tomczhen 2024-02-02 10:49:30 +08:00 via Android
先想想跑满“高性能”的带宽流量费用能不能负担得起，再来谈框架性能瓶颈吧。
|
 |
24
Hider5 2024-02-02 10:58:27 +08:00
哪有那么多高性能场景，我参与了好几轮大促和全链路压测，99.99%的接口 qps 都不上 100
|
 |
25
julyclyde 2024-02-02 10:59:02 +08:00
是指哪个同步啊？
|
 |
26
wanguorui123 2024-02-02 10:59:17 +08:00
大部分情况下瓶颈在数据库。
|
 |
27
Philippa 2024-02-02 11:02:00 +08:00
Django 主要是小公司在用，快速迭代是小公司关注的点，性能只要满足要求即可。有个人开创业公司用 Rust ，后面他写了个文章说以后创业再也不用 Rust 了，虽然安全性能好，但是用别的迭代会更快。
更何况架构合理，可以大规模横向扩展。那时候瓶颈就去了 Database 去了。如果是微服务每个服务配一个 Database ，那性能更不成问题了（或许用 flask 和 fastapi 更合适）。只有到了 Django 无法满足的场景，比如要求低延迟，才有替换 Django 的需要。 |
 |
28
lambdaq 2024-02-02 11:05:23 +08:00
只有我一个人不知道什么是「同步机制性能瓶颈」吗？
说的是没用 asyncio ？别人好像也支持 https://docs.djangoproject.com/en/5.0/howto/deployment/asgi/ 的呀？ |
 |
29
ho121 2024-02-02 11:09:18 +08:00
不出意外的话，瓶颈主要在数据库
|
 |
30
feiniu 2024-02-02 11:12:59 +08:00
我也感觉大部分瓶颈是在数据库
|
 |
31
vicalloy 2024-02-02 11:27:02 +08:00
很多时候性能瓶颈都不卡在 web 框架，而且对于大多情况下也用不到异步。异步框架最大的特点是跑分好看。
Instagram 后端用的是 Django ，包括后来 Instagram 团队出的 Threads （ Facebook 版的 Twitter ）也用了 Django 。 Instagram 用的 Django 自然是魔改过的，但大概率主体还是同步模式。 最后，如果你能触及 Django 的性能瓶颈，那已经很成功了。大多项目在遇到瓶颈前就挂了。 https://news.ycombinator.com/item?id=36612835 |
 |
32
qsnow6 2024-02-02 11:29:39 +08:00
CPU 99%的情况下是闲置的
|
 |
33
lolizeppelin 2024-02-02 11:35:59 +08:00
笑死了...都在用 python 了还在纠结性能问题....
|
 |
34
zhangshine 2024-02-02 11:48:32 +08:00
绝大多数网站用一个普通的$5 美元的 vps 都能支撑，根本没有那么多流量，也用不到那么高的性能。不过我现在不用 django ，单纯因为不想写 python 了
|
 |
35
retrocode 2024-02-02 11:49:44 +08:00
话说你们都是怎么处理 django 的部署问题的, 打 docker? 我比较烦源码部署, 或者 webhook 拉 git, 一堆散碎文件.
|
 |
36
JosephYin01 2024-02-02 11:51:01 +08:00
升級下 server 性能比多招幾個 java 程序猿便宜多了
|
 |
38
hideon 2024-02-02 14:52:11 +08:00
@JosephYin01 nonono ，java 程序员才是最便宜的，思路打开，把 python 全炒了，换 spring
|
 |
39
gokiller 2024-02-02 15:15:46 +08:00
所以面试的时候问那么多高并发的问题就是扯淡的。
我一般关心谁最快把稳定的系统部署上线。 |
 |
41
hackerfans 2024-02-02 17:35:39 +08:00
1 核 2G 1MB 服务器表示 django 性能够用了
|
 |
42
neoblackcap 2024-02-02 20:58:25 +08:00
性能是不是真的低，应该用数据说话。你要求性能应该达到 1000qps ，但是实际上你们的生产环境可能就 10qps ，那不是扯嘛。
而且 web 端那么快，你数据库顶得住？ |
 |
43
DeWjjj 2024-02-02 21:46:59 +08:00 via Android
Python 不行的可以调用 cpp 代码。
|
 |
44
abersheeran 2024-02-02 23:28:20 +08:00
什么同步性能瓶颈？ Django 慢也是相对慢，把 flask 或者 fastapi 功能上满，也不会比 Django 快多少。CPython 性能就在这儿摆着。谁说能比肩 golang 那都是营销手段，吹牛逼的。
|
 |
45
dayeye2006199 364 天前 via Android
因为很多时候耽误赚钱的是程序员的写代码速度，不是代码跑的速度
|
|
46
julyclyde 364 天前
@hackerfans 1MB 有点夸张吧
|
 |
47
VirtualLife 195 天前
django 的 admin 实在太香了。性能什么的，哪有先把业务弄出来跑重要。。看了一下我自己的一个业务，24h 请求 862.91k ，每天大概处理 27k 个 celery 任务（ io 密集的），除了 celery worker 用了 eventlet ，项目本身没有任何异步代码。django / redis / celery / postgresql ，全部运行在一台 8c16g 的 VPS 上，日常内存占用只有 4-5 个 G 左右。这一套东西也稳定运行有半年了。
|
Select Language