很多人都熟悉Twitter通路故障時候那條白色的鲸魚。今年新推出的Twitter Engineering Blog講述了Twitter白鲸技術故障的原因及解決思路。這是到目前為止Twitter公開的最底層的一篇技術資料。
http://engineering.twitter.com/2010/02/anatomy-of-whale.html
當Web Server發生503錯誤後，Twitter配置了一個前端鲸魚的顯示頁面。Twitter對鲸魚頁面有監控體系，當每秒超過100個鲸魚就會引起報警。
1. 分析背景資料
“分析性能問題不是一門科學，而是一門藝術”。
鲸魚頁面實際上是對HTTP 503錯誤的前端展示，503錯誤通常是調用背景請求逾時産生，為了避免使用者長時間等待，Twitter的前端(Tim: 也可能是HTTP反向代理)給請求加了逾時，避免使用者無限制的等待。逾時通常是由于機關時間内通路的使用者數過大，也有可能是背景某個服務突然變慢造成。
由于Twitter網站每個時刻都有海量的資料流過，是以要簡單的定位并解決此問題并不容易。
2. Web page請求分解
Twitter的頁面請求後端分成2個階段，在Twitter内部稱為IO phase及CPU phase。IO phase指通過網絡服務擷取使用者的關注關系及相關的Tweets。第2階段為CPU phase，指将資料聚合、排序及按使用者請求的條件輸出。IO及CPU各自在1天内消耗的時間如下。
從圖上看到，latency增大時IO是主要瓶頸。IO對應于Network service，是以可以判斷是某個網絡服務性能降級造成。
3. 深度分析
理想情況是網絡服務在應答相同參數的請求消耗時間應該基本相同。但實際情況并非如此，我們大膽假設某一網絡服務性能下降厲害，于是我們就從統計分析中去尋找這個服務，我們看到Memcached的統計圖表如下
4. Memcached 竟然是鲸魚故障的直接原因
可提高的空間及解決思路
- 從上圖看，Memcached在 latency高峰的性能比低谷相差一倍，是以最簡單的判斷是增加硬體即可提高50%的性能。
- 另外一種思路就是優化Memcached程式，判斷程式熱點和瓶頸并進行優化。
分析
- 通過 Google perf-tools project 工具來分析, http://code.google.com/p/google-perftools/ http://github.com/tmm1/perftools.rb
- 通過自己些的一段分析代碼來監控 http://github.com/eaceaser/ruby-call-graph
- 通過上面工具的call graph來分析熱點和瓶頸
最後分析資料Memcached請求分布比例如下
get 0.003s
get_multi 0.008s
add 0.003s
delete 0.003s
set 0.003s
incr 0.003s
prepend 0.002s
get 71.44%
get_multi 8.98%
set 8.69%
delete 5.26%
incr 3.71%
add 1.62%
prepend 0.30%
結論：從上面資料來看，調用熱點和瓶頸主要集中在Get操作
是以回頭取看Twitter頁面執行流程代碼，找出優化方法見注釋。
get(["User:auth:missionhipster", # 将昵稱轉換成uid
get(["User:15460619", # 擷取user object(用于檢查密碼)
get(["limit:count:login_attempts:...", # 防止密碼字典攻擊
set(["limit:count:login_attempts:...", # 大部分情況不需要, bug
set(["limit:timestamp:login_attempts:...", # 大部分情況不需要, bug
get(["limit:timestamp:login_attempts:...",
get(["limit:count:login_attempts:...", # 重複調用，可記住
get(["limit:count:login_attempts:...", # 重複調用
get(["user:basicauth:...", # 防止解密的優化
get(["limit:count:api:...", # 請求數限制
set(["limit:count:api:...", # 設定請求數，大部分情況不需要，為什麼？
set(["limit:timestamp:api:...", # 大部分情況不需要, bug
get(["limit:timestamp:api:...",
get(["limit:count:api:...", # 重複調用
get(["home_timeline:15460619", # home_timeline業務調用
get(["favorites_timeline:15460619", # favorites_timeline業務調用
get_multi([["Status:fragment:json:74736693", # multi_get所有tweets内容
結論
- 在前文2010年的技術架建構議中提過Cache已經是Web 2.0系統核心元素。從Twitter的故障案例來看Memcached竟然成為了瓶頸并導緻了Twitter服務的不穩定。由于在social應用中cache核心化的設計，“RAM is the new disk”，在cache廣泛使用後也變得調用成本增加，需要考慮進行系統的規劃減少不必要的調用。避免開發人員在代碼中随意使用cache
- 如何定位瓶頸，可以借鑒Google perf-tools項目及上面其他分析工具的思路。
- Twitter頁面執行流程值得參考
- 整個故障流程分析圖如下