很多人常常會問Ruby/Rails在執行效能、速度、反應時間等等方面的各種問題，特別是當我提到Ruby是Scripting Language的時候。
某程度來說，縱使PHP/Python/Ruby比起C/C++/Java慢上一百倍，我也不認為那是問題，我完全同意DHH對於Ruby/Rails效能問題的回應，並且最欣賞他跟Linus Torvalds一樣，都是一副I’m God的屌樣。
無論使用哪種程式語言，Web App執行效能的最大瓶頸絕對不會卡在程式語言、編譯器本身，而是會出現在Web Server或者資料庫，而這兩者的效能有賴硬體配備的提升。
背後的邏輯就是: 一台Web Server主機撐不起來時，加兩台總可以吧？兩台不夠加四台總可以吧？諸如此類的，後端資料庫也是一樣。
以目前全球最知名的Rails Web App: Twitter來說（別說你不知道什麼是Twitter），它算是驗證Rails效能的最佳實例，目前平均每秒有高達一萬一千次Request (注意是每”秒”)，最近遇到的正是資料庫方面的問題。
簡單的講，效能是可以用錢買到的，但程式員的時間是用錢買不到的。而Ruby的設計哲學”讓程式員快樂”正好可以彌補買不到的程式員時間，”讓程式員快樂”不但可以讓程式員享受工作，更節省開發時間，從而提高生產力。
而Ruby/Rails的強項從來就是在開發速度而非執行速度，不知道擔心效能問題到底有何意義？
如果一個架構只是提升開發效率20%，那就必須擔心其他問題，甚至不要用可能還保險一點；但如果可以提升開發效率300%~500%，那麼其他問題根本不用管，直接用就行了。
話又說回來，Web App不使用Scripting Language是不可能的，愈新或愈往主流靠攏只會用的更多而已，Web 2.0或Ajax不都大量運用JavaScript嗎？而JavaScript不正是運用最廣泛的Scripting Language嗎？
好吧，萬一真的有非常大量的圖表運算，而且完全確定Ruby/Rails在這方面表現極差時，那該怎麼辦呢？
我會反問你，為什麼不把這一小段程式用C或Perl去寫？
把這種工作外包給其他更足以勝任的程式語言，而讓Ruby/Rails盡情發揮在物件導向、快速開發以及讓程式員快樂上頭，那不是更好嗎？
