我是前端,不懂这个数字代表什么,但是东软拿出来炫耀,是表示很牛吗?

2022-09-04 13:49:39 +08:00
 evada

东软核酸检测系统在上海经受住了平均每小时超过 600 万人次的峰值考验,在北京经受住了平均每天超过 2000 万人次的压力考验。

7508 次点击
所在节点    成都
29 条回复
westoy
2022-09-04 13:55:37 +08:00
对外包方案商来说, 我觉得 qps 能超过一千就挺牛的了。 做政企业务方案的, 没哪家主打的是并发啊, 不都是业务的覆盖和完整性么, 一个大集团能有多少并发.....

或者说有大并发需求的, 有几家业务是外包或者整套方案买的方案商的
Torpedo
2022-09-04 13:58:51 +08:00
有一说一,你想想人家的核心竞争力是啥。技术这边能用就行了
lscho
2022-09-04 14:01:19 +08:00
如果真是每小时 600 万人次,每秒 tps 至少 1666 ,qps 至少翻个倍,每秒 3000 。相当牛了。
bigbyto
2022-09-04 14:09:06 +08:00
换算到每秒的话一台 2 核 4g 服务器就可以扛下。当然这么复杂的系统架构不可能这么简单,但这并不是值得炫耀的事。为啥不敢换算成每秒呢,还是因为太拉了……
Rrrrrr
2022-09-04 14:51:12 +08:00
能接单和不能接单的区别
SeaTac
2022-09-04 14:52:28 +08:00
每小时 600 万,平均下来每秒 1666 人次
没做过核酸,不知道做核酸的效率是接近平均分布(一个小时做的人次没有大波动)还是更接近正态分布,假定正态分布,峰值 qps 大概在 3000 到 4000 左右
单从 qps 来说,没什么大不了的,问题在于这个系统的要求是什么,是核酸结果要求在几百 ms 内做到不同客户端 query 结果一致,还是允许有几十分钟到几个小时的延迟

如果有很强的一致性要求的话,那这个数字挺不错的,如果没有的话,就没什么意思了

当然,这顿分析的前提就有点问题,所以结论也不靠谱,就是随便想想而已...
murmur
2022-09-04 16:26:22 +08:00
@seaiaddca 错了,核酸系统的并发只跟大白数量有关,跟成都人数没太大关系

核酸是 20 混 1 的,你录入 20 个人和试管的绑定数据,需要 20 个请求,除了开发者 sb 我找不到任何借口

至于生成核酸二维码,那个就是明文的编码,至少广州是这样,广州把核酸编码的任务给了腾讯小程序,广州弄了 6 个核酸码不是炫富吧,这就是天然的负载均衡
yhxx
2022-09-04 16:32:22 +08:00
每小时 600 万约等于每分钟 10 万。

按照上海官方发布的信息,截至 5 月 5 日,上海已布局设置常态化核酸采样点 9021 个。

我们知道大部分核酸采样点是有相互错开的固定工作时间的,不可能同时运行,按最大计算,最多也就一半能同时采样。

我们按 4000+个采样点来算,平均每分钟每个采样点需要扫码+采样 25 人次才能达到东软发布的 600 万次 /小时的数量。

实际同时开放的采样点能有 1/4 就已经很不错了,几乎每秒一次的采样频率,可以吹一波东软速度了
justanetizen
2022-09-04 16:33:42 +08:00
12306 不就是这卵样吗,最开始垃圾的要死,后面堆积起就搞成现在那样了
winglight2016
2022-09-04 16:33:53 +08:00
即使这个数字我也是不信的,平均 600 万 /小时,一天 24 小时,意味着 1.4 亿人次,这是给上海加了 7 倍人口。北京的数据就更有问题,明显是从北京总人口数推出来的。
hiro0729
2022-09-04 17:14:12 +08:00
“孙(去掉)春(去掉)兰 东(去掉)软” Google 下,就知道了技术之外的东西
paullee
2022-09-04 18:25:28 +08:00
那是因为成都这几天全员核酸,晚上雨中排队,系统经常崩溃,P 民苦不敢言。东软此举算是把锅磨小点。群里都有段子,物业催促业主下楼做核酸的口号是:快来做核酸,马上要切到东软的系统了。
huangmingyou
2022-09-04 19:44:36 +08:00
今天成都听到天空传来一声巨响,知情人士透露是东软甩的锅。
bitdepth
2022-09-05 00:18:58 +08:00
上海那個垃圾核酸碼是不是就是東軟的?開頭幾天塞爆了,後面改手動分流
GopherDaily
2022-09-05 00:41:28 +08:00
6000000 / 3600 = 1667
mingl0280
2022-09-05 07:28:40 +08:00
很拉的说法,完全体现了系统宣传人员既不懂技术也不想懂技术的心态
zhou405x
2022-09-05 09:21:06 +08:00
人笑麻了 . 6000000/3600 = 1666.6667
平均每秒 qps 1666 . 这还是峰值 ,
但是底层没有复杂业务逻辑, 就是简单的查一下数据 , 你弄个大点的 redis 或者本地缓存就可以了.
redis 能支持 10w qps , 整一个 ng 路由 + 本地缓存的话那就更快了 .
啥也不是
jvCrystal
2022-09-05 09:33:53 +08:00
@zhou405x 应该是读写都会有,不仅仅是读
zhou405x
2022-09-05 10:03:50 +08:00
@jvCrystal 典型的读多写少场景 , 加上本身就没有强一致性的要求, 所以使用缓存的话问题不大
unco020511
2022-09-05 10:24:16 +08:00
我觉得这个系统很简单啊,首先就是大白扫管子上的码,然后依次扫 10 个人的健康码,在本地将这 10 个人的信息+管子的信息一次性上报服务,假设 20 秒一个人,那就是一个终端 3 分钟才 post 一次,并且多个终端之间还不存在读写一致性的问题(一个人不可能同时在多个队伍排队做核酸,核酸结果查询是健康码系统,与核酸系统无关).真不觉得这个玩意有什么技术难度

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/877606

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX