Twitter 是用 RoR 開發(fā)的流量最大的站點(diǎn). 應(yīng)用了 Rinda，其 基于 DRb使用DRb (”Distributed Ruby”.), 該庫可以通過 TCP/IP 從遠(yuǎn)程 Ruby 對象發(fā)送接收消息,
,還用到了erlang技術(shù)中著名的 ejabberd。

5月9日，其官方網(wǎng)站上登信息辟謠， Twitter沒有計(jì)劃放棄ruby on rails，早就開始使用了混合語言改進(jìn)性能。

為什么這個(gè)謠言傳得這么快，這么像真的？

許多人總是擔(dān)心rails的性能問題，一旦網(wǎng)站穩(wěn)定性出了問題，首先考慮是rails撐不住了。

真實(shí)的情況是這樣的：

1）網(wǎng)站和傳統(tǒng)java,delphi桌面或企業(yè)應(yīng)用程序不同，大部分性能不是來自語言，而是來自應(yīng)用設(shè)計(jì)。

2）目前twitter可以支持每秒11000個(gè)請求，性能已經(jīng)夠了。
這是什么概念？假設(shè)1000萬個(gè)用戶，每個(gè)用戶平均每天發(fā)10個(gè)帖子，每秒也就1000個(gè)帖子。
如果1000萬個(gè)用戶，每人運(yùn)行一個(gè)客戶端來發(fā)貼，24小時(shí)內(nèi)每15分鐘發(fā)一貼，每秒為10000個(gè)帖子。
現(xiàn)在twitter的規(guī)模還不到1000萬用戶，更沒有每天如此活躍的1000萬用戶和客戶端。

3）系統(tǒng)宕機(jī)的原因是有些惡意的程序通過API發(fā)帖，在瞬間超過了11000個(gè)以上。
系統(tǒng)必須通過限制程序的短時(shí)間內(nèi)發(fā)帖總量，避免惡意程序破壞。
誰在做這些事？SEOer，twitter排名靠前， PR高， 發(fā)帖有API接口，很容易快速建立反向鏈接，許多人都在做這些發(fā)帖。也有些好奇者用極端情況測試，比如24小時(shí)增加9000個(gè)朋友。
有效地控制一個(gè)合理上限，是應(yīng)用設(shè)計(jì)的一個(gè)關(guān)鍵。
為了徹底滅掉SEOer的行為，twitter已經(jīng)去掉了帖子中的鏈接。
對于極端用戶，已經(jīng)做了封閉帳號或刪除處理。
還使用了一系列方式檢測這些問題。

4）目前性能足夠，所以twitter沒有使用數(shù)據(jù)分區(qū)存儲(chǔ)，還是Master-slave架構(gòu)。
相信要提升空間，還有很大余地。比如將用戶按照地區(qū)或名稱計(jì)算hash值，分配到10個(gè)或更多的數(shù)據(jù)庫服務(wù)器上。

twitter平臺(tái)如下：
------------------------------------------------
Ruby on Rails
Erlang
MySQL
Mongrel
Munin
Nagios
Google Analytics
AWStats
Memcached

據(jù)說twitter目前的運(yùn)行狀態(tài)如下：
------------------------------------------------
每秒鐘600請求
每秒鐘平均200-300個(gè)連接，峰值為800個(gè)連接
MySQL每秒鐘處理2，400個(gè)請求
180個(gè)Rails實(shí)例，使用Mongrel作為Web服務(wù)器
1個(gè)MySQL服務(wù)器(one big 8 core box)和1個(gè)slave用于只讀的統(tǒng)計(jì)和報(bào)告
30+進(jìn)程用于處理其余的工作
8臺(tái)Sun X4100s
Rails在200毫秒內(nèi)處理一個(gè)請求
花費(fèi)在數(shù)據(jù)庫里的平均時(shí)間是50-100毫秒
超過16GB的memcached

Twitter沒有計(jì)劃放棄ruby on rails，而且早就用了erlang改進(jìn)性能