Twitter , Rails , Scalibility...More
Twitter 是一個最近非常熱的 Web Site，他們主要是可以利用簡訊，網頁更新自己的近況。Twitter 的開發者 Alex Payne 在接受訪問的時候，拋出了一個震撼性的議題Rails Scalibility 到底好不好的問題夠震撼吧。我發現到很多人都開始發表了 「Rails 遇到效能上的問題...」。看到只能說，這是 Rails 社群第一個大挑戰，但是請不要太過武斷就直接認為是 Rails 的問題。如果大家仔細了解這個事情的情況，就可以大略推估應該是 Twitter Team 成功的太快，整個 team 的成長跟不上網站的成長速度。我們來看看到底事情的始末。
故事開始
Alex Payne 是 Twitter Team 其中一員，他接受了 Radical Behavior 的訪問，當被問到 Ruby on Rails 如何應付高速成長的流量時，他指出他認為 Ruby on Rails 有不少 Scability 的議題，Alex 的論點如下
- Ruby is slow
- Rails 一次不能 connection multi database
- Rails 有些東西 component，性能消耗太大，必須不去使用
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至於 Rails 一次連結到多個 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？我認為這個 case 無法認定那一個結論是正確的。我們看看 twitter 的流量成長
很明顯的，Twitter 在 2007 年的流量是一個暴發戶的成長方式，通常網站遇到了這樣突然爆增的流量，原本編制的 RD 跟網管應該都完全無法應付吧，那麼一時之間無法解決也是非常正常的事情。所以，他們應該也不是太懶惰，只是成功的太突然，沒辦法吃下來。再來，根據Blaine Cook 在 SDForum 發表的「Scaling Twitter」投影片，他們一共有 180 Mongrel Instances，但是卻只有使用兩個 DB Server，這似乎完全不符合一般大網站所遇到的情況（就是一海票的 DB Server，每個 table 都是橫切縱切隨便切）。當然我們不排除 twitter 的 application 型態其實並不需要太多 DB 的 request ，不過180 Mongrel Instant 居然只有 兩台 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 是可以被克服的議題，也是值得一起去加油的議題。
延伸閱讀
