要證明Rails的伸縮性，最好的辦法莫過於考察一個確實有效伸縮的應用程序。在這裡我們將考察三個真實應用遇到的性能問題，以及它們如何解決這些問題。
37signals開發的Basecamp
Rails就誕生於Basecamp項目。這是一個基於web的項目管理工具，它的用戶需要每月付款。Basecamp服務器為成千上萬的用戶提供項目管理所需的功能服務。
在為Basecamp進行性能優化時，最大的難題在於很難使用緩存：每個人都來自不同的公司、有著不同的權限，因此看到的數據也各有不同。（不過從好的方面來說，只有那些擁有注冊賬號的人才能訪問Basecamp，所以不用擔心它會被Slashdot介紹而帶來一大堆未授權的用戶。）
Basecamp每天處理大約40萬個動態請求（從看到登錄頁面開始算起，直到浏覽項目記錄板，所有的請求都包含在內）。在無法做任何緩存的情況下，這個負載量是相當可觀的。目前有兩台web/應用服務器來處理這些請求，每台服務器都有兩個至強2.4GHz CPU和2GB內存，運行15個FastCGI進程和50-100個Apache 1.3.x進程。服務器的負荷比通常在0.5到1.5之間。
MySQL數據庫服務器是獨立的，但37signals的另外兩個應用程序（Ta-da List和Backpack）也使用這個數據庫。數據庫裡的記錄數在十萬級別上，最大的一張表有大約50萬條記錄。雖然要為三個應用程序提供服務，但數據庫服務器的負荷比通常在0.1到0.3之間——數據庫不是Basecamp的瓶頸所在，這是一個好消息。如果當前的兩台服務器不堪重負，只要再加上新的服務器就可以解決問題，而且我們也確實這樣做了。
Robot Co-op開發的43 Things
43 Things是一個用於“追蹤人生目標”的站點。你可以在這裡寫上你的目標，譬如“我要學日語”，圍繞著這個目標撰寫blog，並閱讀別的有同樣目標的人在干什麼。這個應用程序的一部分需要身份認證；更多的部分則是公開的，允許未經授權的用戶訪問。公開內容訪問量常有劇烈的變化；不過還好可以對它們進行緩存。
緩存的存儲策略采用了memcached——為了改善性能，這個網站大量使用了memcached。由於將用戶的session數據保存在memcached中，任何一台服務器都可以在任何時候處理來自任何用戶的請求，而不需要任何session同步措施。對於開銷較大的數據庫查詢，其結果也以ActionRecord對象的形式被序列化到memcached中，並打上適當的時間戳。
上線三個月之後，43 Things每天處理約20萬個動態請求。它使用了兩台web/應用服務器，以及一台專用的數據庫服務器，三台機器都有兩個3GHz的至強CPU和2GB內存。兩台web/應用服務器上分別運行著Apache 1.3.x服務器和25個FastCGI進程。服務器負荷比很少超過0.3，CPU空閒時間經常在80%左右。
抵押處理引擎
Rapid Reporting將他們的“身份及收入驗證引擎”運行在Rails系統上。美國1000強的抵押擔保商有80%都使用這套引擎，每月處理2百萬次抵押申請交易。
一開始，Rapid Reporting希望檢驗Rails是否能夠勝任，因此他們從10台集群機器向一個應用程序進行壓力測試，每秒發起3千次請求。真實的應用程序大概需要每秒處理300次請求，並執行一系列的業務邏輯。此外，處理抵押業務必須遵循格萊姆-布裡勒法規（GLBA），因此很多地方都需要檢查授權許可、生成查賬索引。
應用程序使用PostgreSQL作為數據庫，lighttpd作為web服務器，每台應用服務器運行大約10個FastCGI進程，在一台虛擬服務器上用IP隧道技術實現負載均衡（參見http://www.linuxvirtualserver.org/VS-IPTunneling.html）<!--[if !supportFootnotes]-->。使用這種部署方式，就可以隨時增減FastCGI進程，而不必重啟web服務器。由此又可以實現進程管理的自動化：用一個守護進程監視負載情況，當負載達到峰值時分配更多的FastCGI進程。
這是一個真正的商業應用。這些東西聽起來也許很乏味，但是否了解它們也許會決定你是否能夠得到客戶的認可。
