※ 引述《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沒有說明
這邊的沒有說明為,開發一套環境,但沒討論到負荷量,
也就是第二點的客人數量,如果真的沒有,這點絕對是開發的致命傷,
產品開發必備幾個階段,[協商->開發->測試->上線]
可以發現"協商"絕對是第一個階段(中途改需求,不討論),
它影響著開發如何達到需求,測試如何列下測試條件,上線如何給交代.
至於真實原因,可能等官方報告了!