某懶人包所忽略的因素
by thinker
關鍵字:
最後更新時間: 2015-01-15 10:45:26 CST | 引用
查詢:
COMMENTS:
on 2015-01-20 16:30:10 CST
Ant said ..
既然被點名了,稍微說明一下。我從來不評論寬宏系統應該怎麼做,批評這事我也沒什麼興趣,確實系統有改善之處,不過「不入流」這詞我倒不會貼在寬宏事件上。 我承認這個推算絕對有問題,這點從來不否認。使用者會狂按 Refresh 也絕對是需要考量的。 不過既然寬宏官方都說當日高達 35 萬"人次"擁入,那麼我也只是順著本身命題的錯誤嘗試推翻這個論點罷了。("人次",官方可是認定每 Refresh 都會加一喔) 最後,早在發該文前,經由管道我已得知寬宏確實無法處理每秒超過四百的訂票量,所以順水推舟找了個接近這個數字的推算而已。
on 2015-01-20 18:07:52 CST
Thinker said ..
「不管是 Web server 或 database ,即使塞住,恢復時間也不過數秒 內,不可能超過一分鐘」 其實很容易就超過,一旦動到 swap, 開始 thrashing,一分鐘算是小 case。
on 2015-01-22 04:57:42 CST
Ant said ..
這事件上我確實沒有考量 swap 或甚至 IO contention 的因素,因為我得到的數據顯示,寬宏的問題可能不是發生在記憶體上。就手邊資料來看,系統卡住時,沒有看到 swap 顯著發生,但這只是某個時間點片面的資訊,還無法推論到整體系統的問題。至於問題出在哪裡,老實說還需要更多的數據。