360360 wrote:
轉貼自跑者廣場家成:...會造成當機原因 是我們在採購時候 沒有考慮到流量超過量 超大量問題
恆碩公司 提供 1200 筆 /小時 流量 (11/28 下午 及11/30 開放後都符合標準)
2012櫻花馬 4天 才報完3500位 我們認為今年足夠應付 才沒有考慮到秒殺問題
總之問題起源
是我們採購時流量規格沒有特別要求調高 不能全部歸責 恆碩公司
我們要負責最大部分責任 ....(恕刪)
這個坦白講如果是資訊業同業一看就知道是犯了不可思議的錯, 主辦單位採購組如果沒有從事資訊業的成員, 好歹也有從事資訊業的朋友, 再不然問一問也知道 1200 筆/小時 這種規格是很有問題的開法
1200 筆/小時, 換算起來的話是 20 筆/分鐘, 也就是只要一筆交易平均 3 秒內可以完成就 ok, 這只單純規範到 transaction time, 但是 concurrent user 數多少卻支字未提, 1200 筆/小時 這種規格你可以慢慢每 3 秒一筆 single thread 餵給系統, 你也可以 1200 個 thread 一次餵給系統, 以本次的狀況來講不要說同時 1200 u, concurrent 100 u 系統搞不好都撐不住, 當天系統是掛在「同時上線人數超過系統負荷」, 而不是「一小時內交易量太多」, 是沒錯, 規格都搞不清楚所以不能全部歸責報名系統承攬廠商, 但是連規格都搞不清楚而且犯下這種可怕的錯誤承辦單位是不是應該打屁股?? 3 秒鐘完成一筆交易, 我坦白講找部 486 當 web 兼 db server 都作得到, 主辦單位犯的錯多離譜這樣夠清楚了吧
說說回來如果廠商在規格上也只提供 1200 筆/小時這種「標準」但是對「同時上線人數」卻沒有提, 那這廠商的優劣也就很明顯了, 在此建議各項賽事主辦單位, 如果貴單位打算外包報名系統, 對於系統所能提供的「保證頻寬」、「同時上線人數」、「單次交易最長時間」這三項以及廠商使用的硬體設備為何至少一定要列明在合約內, 實際開始報名前務必進行壓力測試, 實在來不及或因故無法會同進行壓測好歹也要請廠商出具壓力測試報告, 同時對系統因超過負荷而導致 crash 時的處理方案及處理時間也必需列有詳細的說明才行, 否則像櫻花馬這種被跑友譙的翻的狀況很快就會再發生
再者, 拜託櫻花馬主辦單位採購組, 如果貴主辦單位明年度還想繼續辦比賽, 仍然想繼續外包報名系統, 拜託找個懂系統的人幫忙看看合約及規格再決定合作廠商吧, 不然被打一萬次屁股都不夠的!!
