Twitter , Rails , Scalibility...More

Twitter 是一個最近非常熱的 Web Site，他們主要是可以利用簡訊，網頁更新自己的近況。Twitter 的開發者 Alex Payne 在接受訪問的時候，拋出了一個震撼性的議題

他覺得 Rails Scalibility不好

夠震撼吧。在這個時刻，我發現到很多人都開始發表了 「Rails 本來就有效能上的問題...barabara....看來 Rails 社群要完蛋了 ........」。看到只覺得很想笑，因為如果大家仔細了解這個事情的情況，就知道 Twitter team 應該不是處於一個正常的狀況，應該是 Twitter Team 成功的太快，整個 team 的成長跟不上網站的成長速度。我們來看看到底事情的始末。

故事開始

Alex 的論點如下

1. Ruby is slow
2. Rails 一次不能 connection multi database
3. Rails 有些東西 component，性能消耗太大，必須不去使用

此話一出，當然引起了 Rails 社群的積極辯護，跟其他語言社群基於「良心」的建議。當然，我們 Rails 社群當中的老大DHH ，也不落人後的提出相關的建議。DHH 似乎覺得 Twitter 有點太過於懶惰了點，Twitter 比很多人幸運，有機會碰到那麼大的流量，那就該好好的想辦法處理相關的問題。而不是等著別人幫你解決你應該解決的問題。Open source 的成功，是來自使用者遇到相關的問題，並且解決他，回報給社群，這樣社群才會繼續壯大起來。

Second, when you work with open source and you discover new requirements not met by the software, it's your shining opportunity to give something back. Rather than just sit around idle waiting for some vendor to fix your problems, you get the unique chance of being a steward of your own destiny. To become a participant in the community rather than a mere spectator. This is especially true with frameworks like Rails that are implemented in high-level languages like Ruby. The barriers to contribution are exceptionally low

至於 Connect to Multi DB 的問題，老實說，這根本不是問題，Dr. Nick 早就提出了Magic Multi Connections，可以有效解決這個問題。至於 Twitter 團隊是不知道這個東西，還是試過這個 Plugin 之後發現不夠用呢？InfoQ 訪問了 Twitter 另外一個開發者 Blaine Cook，說到 Dr. Nic 的 Plugin 很棒，很有幫助， Blaine Cook 表示目前 Twitter 的 DB Connection 是 600 req/sec，雖然很高，但是現在 Twitter 沒有暫時 DB 的問題。（那之前 alex 不是質疑說他們的問題是在 DB ? 到底 Twitter Bottleneck 在那裡？有點不了解他們的 Point 。）

"Dr. Nic's approach is a great first step, and adds some welcome helpers to selecting from a number of database connections." but noted that "Twitter isn't currently database bound, and won't be for a while yet"

這時 Dr. Nic 也出來打圓場了，他說「Twitter 已經貢獻了 Jabber API 了」，其實不用苛求太多啦。

The guys at Twitter have already contributed code to Ruby community (Jabber API)

話說回來，Twitter Team 也似乎感受到 Rails 社群對他們處於制高點的期待，也開始對社群做出了幫助。Blaine Cook 在 SDForum 發表了 「Scaling Twitter」，裡面提到許多他們的問題以及解決方式。

進入討論

OK ，我們已經把故事講完了，現在討論正經點的事情。

到底是 Twitter 技術上不夠厲害，或是 Rails 不夠 Scalibility？

我認為很多人藉由這件事情發表了有點武斷的結論。我們看看 twitter 的流量成長
很明顯的，Twitter 在 2007 年的流量是一個暴發戶的成長方式，通常網站遇到了這樣突然爆增的流量，原本編制的 RD 跟網管應該都完全無法應付吧，那麼一時之間無法解決也是非常正常的事情。所以，他們應該也不是太懶惰，只是成功的太突然，沒辦法吃下來。

再來，根據Blaine Cook 在 SDForum 發表的「Scaling Twitter」投影片，他們一共有 180 Mongrel Instances，但是卻只有使用兩個 DB Server，這似乎完全不符合一般大網站所遇到的情況（就是一海票的 DB Server，每個 table 都是橫切縱切隨便切）。當然我們不排除 twitter 的 application 型態其實並不需要太多 DB 的 request ，不過兩台 DB Server 未免也太少了點。

Twitter 是 host 在 joyent 上面的，像這種有一定規模的網站公司居然沒有自己專屬的系統管理者，光是這點這就看出 Twitter 成長真的太快了。一般來說，Web Host 很難做到專門為某個 Service 最佳化吧。Scalibility 本來就是軟體開發者跟系統管理者並肩合作的工程，Twitter 該多請幾個系統設計師摟。

至於 Ruby 是不是真的太慢，Rails 是不是真的不夠 Scalibilty呢？這個問題我也不知道，畢竟我沒 run 過那麼大的 site，而我看到的 site 都是效率很不錯的。LAMP 發展了很久，Java 跟 Python 發展了很久，他們擁有 Ruby and Rails 社群無法比擬的成熟度，這是不爭的事實。但是，為什麼 Rails 會讓那麼多人趨之若騖，而非那些其他的語言呢？

那是因為 Ruby on Rails 擁有一些別人沒有的東西。而那些東西是很難被取代的。

今天這件事情沒有誰對誰錯，Twitter 點出這個議題，並且強調這個議題的重要性，Rails 社群接收到 Twitter 的訊息，大家一起幫忙解決，這是一個良性的溝通。我相信 Scalibility 是可以被克服的議題，也是值得一起去加油的議題。


延伸閱讀

• Alex 訪談原文：5 Question Interview with Twitter Developer Alex Payne
• DHH 回應
• InfoQ 原文，簡體中文翻譯
• d.cat blog 對這件事情的討論