※ 引述《A1bertPujols (The Machine)》之铭言：
: 是这样啦，听说有人架了一个预约网站
: 说起来是吓死人，结果是笑死人
: 现在喊冤说一分钟有6000人
: 一分钟六千人，大概是一秒100人
: 一秒钟100人同时在线
: 却爆炸当机的系统大概是什么等级？
先说结论,很糟糕,
拿一个例子比较,购物网站的秒杀,
他们的要求 是 几秒/1000人 2000人计算,
对岸或是国外市场甚至是秒/10000在跑,
这也是常讲的,我们要C10K的负荷能力,
至于现在1分钟/6000人 秒/600 就爆炸,
恩.....不能直视.....
随手写了一个Spring的接收测试Sev,
Jmeter开测试,参数为12Thread,10ms间格传送插入请求,共6000请求
不到10秒就结束.....,即便加上网络传输延迟,
也没遇过这么扯的.........
至于预约网站遇到的困难,
这边猜想几个较直观的可能性 :
1. 机台老旧
有可能是20年老旧机台,
这点最好解决,2,30W就可以买一台正常的硬件Ser.
2. 程式请求消费阻塞
这里用餐厅做举例当一瞬间来了2,30客人时,
店内3个服务员,一定是接单,写完后送中央厨房,
继续接其他客人单,等待餐点处理好,在透过服务员返回客人,
若,服务员接完单到将餐点返回给客人后,才接续下一个客人服务,
这样客人绝对是排队排到死,也就是请求阻塞,
这部分可能发生在Http请求/内部系统验证/SQL执行等......架构设计问题
可参考 NHK认证粉丝团或相关友善KOL的图文分享,一分钟刷新600 PO文,
真是厉害.
3. Spec没有说明
这边的没有说明为,开发一套环境,但没讨论到负荷量,
也就是第二点的客人数量,如果真的没有,这点绝对是开发的致命伤,
产品开发必备几个阶段,[协商->开发->测试->上线]
可以发现"协商"绝对是第一个阶段(中途改需求,不讨论),
它影响着开发如何达到需求,测试如何列下测试条件,上线如何给交代.
至于真实原因,可能等官方报告了!