

django 的同步机制有性能瓶颈为什么还是有很多人用?
source link: https://www.v2ex.com/t/1013560
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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