Ruby 語(yǔ)言常以其靈活性為人所稱(chēng)道。正如 Dick Sites 所言，您可以 “為了編程而編程”。Ruby on Rails 擴(kuò)展了核心 Ruby 語(yǔ)言，但正是 Ruby 本身使得這種擴(kuò)展成為了可能。Ruby on Rails 使用了該語(yǔ)言的靈活性，這樣一來(lái)，無(wú)需太多樣板或額外的代碼就可以輕松編寫(xiě)高度結(jié)構(gòu)化的程序：無(wú)需額外工作，就可以獲得大量標(biāo)準(zhǔn)的行為。雖然這種輕松自由的行為并不總是完美的，但畢竟您可以無(wú)需太多工作就可以獲得很多好的架構(gòu)。

例如，Ruby on Rails 基于模型-視圖-控制器（Model-View-Controller，MVC）模式，這意味著大多數(shù) Rails 應(yīng)用程序都可以清晰地分成三個(gè)部分。模型部分包含了管理應(yīng)用程序數(shù)據(jù)所需的行為。通常，在一個(gè) Ruby on Rails 應(yīng)用程序中，模型和數(shù)據(jù)庫(kù)表之間的關(guān)系是 1:1；Ruby on Rails 默認(rèn)使用的對(duì)象關(guān)系映射（ORM）ActiveRecord 負(fù)責(zé)管理模型與數(shù)據(jù)庫(kù)的交互，這意味著 Ruby on Rails 程序通常都具有（如果有的話）很少量的 SQL 代碼。第二個(gè)部分是視圖，它包含創(chuàng)建發(fā)送至用戶的輸出所需要的代碼；它通常由 HTML、JavaScript 等組成。最后的一個(gè)部分是控制器，它將來(lái)自用戶的輸入轉(zhuǎn)變?yōu)檎_的模型，然后使用適當(dāng)?shù)囊晥D呈現(xiàn)響應(yīng)。

Rails 的倡導(dǎo)者通常都樂(lè)于將其易用性方面的提高歸功于 MVC 范型 — 以及 Ruby 和 Rails 二者的其他一些特性，并稱(chēng)很少有程序員能夠在較短的時(shí)間內(nèi)創(chuàng)建更多的功能。當(dāng)然，這意味著投入到軟件開(kāi)發(fā)的成本將能夠產(chǎn)生更多的商業(yè)價(jià)值，因此 Ruby on Rails 開(kāi)發(fā)愈發(fā)流行。

不過(guò)，最初的開(kāi)發(fā)成本并不是事情的全部，還有其他的后續(xù)成本需要考慮，比如應(yīng)用程序運(yùn)行的維護(hù)成本和硬件成本。Ruby on Rails 開(kāi)發(fā)人員通常會(huì)使用測(cè)試和其他的敏捷開(kāi)發(fā)技術(shù)來(lái)降低維護(hù)成本，但是這樣一來(lái)，很容易忽視具有大量數(shù)據(jù)的 Rails 應(yīng)用程序的有效運(yùn)行。雖然 Rails 能夠簡(jiǎn)化對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)，但它并不總是能夠如此有效。
Rails 應(yīng)用程序?yàn)楹芜\(yùn)行緩慢？

Rails 應(yīng)用程序之所以運(yùn)行緩慢，其中有幾個(gè)很基本的原因。第一個(gè)原因很簡(jiǎn)單：Rails 總是會(huì)做一些假設(shè)為您加速開(kāi)發(fā)。通常，這種假設(shè)是正確而有幫助的。不過(guò)，它們并不總能有益于性能，并且還會(huì)導(dǎo)致資源使用的效率低下 — 尤其是數(shù)據(jù)庫(kù)資源。

例如，使用等同于 SELECT * 的一個(gè) SQL 語(yǔ)句，ActiveRecord 會(huì)默認(rèn)選擇查詢上的所有字段。在具有為數(shù)眾多的列的情況下 — 尤其是當(dāng)有些字段是巨大的 VARCHAR 或 BLOB 字段時(shí) — 就內(nèi)存使用和性能而言這種行為很有問(wèn)題。

另一個(gè)顯著的挑戰(zhàn)是 N+1 問(wèn)題，本文將對(duì)此進(jìn)行詳細(xì)的探討。這會(huì)導(dǎo)致很多小查詢的執(zhí)行，而不是一個(gè)單一的大查詢。例如，ActiveRecord 無(wú)從知道一組父記錄中的哪一個(gè)會(huì)請(qǐng)求一個(gè)子記錄，所以它會(huì)為每個(gè)父記錄生成一個(gè)子記錄查詢。由于每查詢的負(fù)荷，這種行為將導(dǎo)致明顯的性能問(wèn)題。