對於網站經營者、創業者來說，延展性的問題是在網站流量成長過程中勢必會面對的問題，如何建立一個具有延展性的架構(scalable architecture)便是在規劃網站事業過程中不可或缺的專業知識。
如果服務本身的功能性合乎使用者需求，卻因為架構、程式效能、資料庫效能的問題導致服務成長出現瓶頸，如何評估、分析網站效能瓶頸？釐清問題後如何找出對應的解決方案，可以思考的相關議題可能包括：
- 如何有效率地釐清問題？從使用者端的數據（讀取時間）或是從伺服器端的log檔案、硬體的負載率？
- 網站效能瓶頸是出現在Client或Server端？是資料庫撐不住還是程式效能不好？是Request太多還是檔案太大？
- Web Server、DB server如何擠出更多的資源？擠不出資源後如何擴展？擴展後會遇到什麼問題？
Twitter身為全球最大的微網誌服務，運用數千台的伺服器提供服務給來自全球各地的使用者，然而每當網站內容、應用程式有更新時，如何盡可能地在越短的時間內將程式碼部署(deploy)到所有的伺服器便是相當重要的課題。
Twitter的開發部落格上的一篇文章：「Murder: Fast datacenter code deploys using BitTorrent」分享了Twitter如何持續改善應用程式的部署流程，在過去Twitter使用Capistrano部 署應用程式，Capistrano是許多Ruby/Rails使用者（當然也有其他語言的開發人員會使用）用來部署程式碼的一個開源專案，開發人員在部署 程式碼的過程都可以透過自動化的部署流程來簡化經常重複的動作，尤其在專案必須同時部署到多台應用程式伺服器時會特別方便。
Twitter在早期便依賴Capistrano來進行應用程式的部署，每當有新版本的程式碼需要釋出時，Capistrano會根據預設好的各種 設定、流程到Twitter所有的伺服器上進行更新的動作，在過去伺服器還不多的情況下一切都很美好，但隨著Twitter伺服器數量的成長，到了幾百台 伺服器時，事情已經不再像過去一樣美好，甚至到後來擁有數千台伺服器時，更新的作業會耗費40分鐘。
Twitter針對這個問題，認為問題的關鍵在於：使用集中式的系統，也就是所有的伺服器要輪流排隊到同一台版本控制系統上進行程式碼更新。 Twitter最初的想法是將版本控制系統也做出分散式的架構，伺服器的程式碼更新就可以分散到不同的機器來壓縮部署時間，但事實上版本控制系統即使分散 在多台伺服器上，也同樣會有這些伺服器要更新檔案的時間。因此Twitter發現或許是需要一個完全去中心化、最好像是BitTorrent，利用P2P 的特色讓所有的節點都可以協助進行程式碼的更新。
以結果來看，在採用了BitTorrent的方式來更新程式碼後，部署的時間從40分鐘大幅減少到只要12秒鐘！實在是非常驚人的改善，數千台伺服器的程式碼居然只要短短12秒鐘就能完成。
Twitter也將此次部署流程改善的成果分享出來，專案名稱叫做Murder，如果對於技術細節有興趣的讀者，可以再進行深入的研究；筆者簡單摘錄幾個重點如下：
- Murder是以BitTornado為基礎開發出來的（BitTornado是某一種BitTorrent client）
- Murder的定位是「協助我們快速的將檔案部署到大批伺服器上」
- 利用BitTorrent的部署方式可避免防火牆的問題、擁有非常快的傳輸速度
- 實際的部署程式碼是搭配Capistrano進行，網頁上有很清楚的說明
