Ruby 語(yǔ)言常以其靈活性為人所稱道。正如 Dick Sites 所言，您可以 “為了編程而編程”。Ruby on Rails 擴(kuò)展了核心 Ruby 語(yǔ)言，但正是 Ruby 本身使得這種擴(kuò)展成為了可能。Ruby on Rails 使用了該語(yǔ)言的靈活性，這樣一來(lái)，無(wú)需太多樣板或額外的代碼就可以輕松編寫高度結(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 二者的其他一些特性，并稱很少有程序員能夠在較短的時(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)題。

其他的挑戰(zhàn)則更多地與 Ruby on Rails 開(kāi)發(fā)人員的開(kāi)發(fā)習(xí)慣和態(tài)度相關(guān)。由于 ActiveRecord 能夠讓如此眾多的任務(wù)變得輕而易舉，Rails 開(kāi)發(fā)人員常常會(huì)形成 “SQL 不怎樣” 的一種態(tài)度，即便在更適合使用 SQL 的時(shí)候，也會(huì)避免 SQL。創(chuàng)建和處理數(shù)量巨大的 ActiveRecord 對(duì)象的速度會(huì)非常緩慢，所以在有些情況下，直接編寫一個(gè)無(wú)需實(shí)例化任何對(duì)象的 SQL 查詢會(huì)更快些。

由于 Ruby on Rails 常被用來(lái)降低開(kāi)發(fā)團(tuán)隊(duì)的規(guī)模，又由于 Ruby on Rails 開(kāi)發(fā)人員通常都會(huì)執(zhí)行部署和維護(hù)生產(chǎn)中的應(yīng)用程序所需的一些系統(tǒng)管理任務(wù)，因此若對(duì)應(yīng)用程序的環(huán)境知之甚少，就很可能出問(wèn)題。操作系統(tǒng)和數(shù)據(jù)庫(kù)有可能未被正確設(shè)置。比如，雖然并不最優(yōu)，MySQL my.cnf 設(shè)置常常在 Ruby on Rails 部署內(nèi)保留它們的默認(rèn)設(shè)置。此外，可能還會(huì)缺少足夠的監(jiān)控和基準(zhǔn)測(cè)試工具來(lái)提供性能的長(zhǎng)期狀況。當(dāng)然，這并不是在責(zé)怪 Ruby on Rails 開(kāi)發(fā)人員；這是非專業(yè)化導(dǎo)致的后果；在有些情況下，Rails 開(kāi)發(fā)人員有可能是這兩個(gè)領(lǐng)域的專家。

最后一個(gè)問(wèn)題是 Ruby on Rails 鼓勵(lì)開(kāi)發(fā)人員在本地環(huán)境中進(jìn)行開(kāi)發(fā)。這么做有幾個(gè)好處 — 比如，開(kāi)發(fā)延遲的減少和分布性的提高 — 但它并不意味著您可以因?yàn)楣ぷ髡疽?guī)模的減少而只處理有限的數(shù)據(jù)集。他們?nèi)绾伍_(kāi)發(fā)以及代碼將被部署于何處之間的差異可能會(huì)是一個(gè)大問(wèn)題。即便您在一個(gè)性能良好的輕載本地服務(wù)器上處理小規(guī)模的數(shù)據(jù)已經(jīng)很長(zhǎng)一段時(shí)間，也會(huì)發(fā)現(xiàn)對(duì)于擁塞的服務(wù)器上的大型數(shù)據(jù)此應(yīng)用程序會(huì)有很明顯的性能問(wèn)題。

當(dāng)然，Rails 應(yīng)用程序具有性能問(wèn)題的原因可能有很多。查出 Rails 應(yīng)用程序有何潛在性能問(wèn)題的最佳方法是，利用能為您提供可重復(fù)、準(zhǔn)確度量的診斷工具。

檢測(cè)性能問(wèn)題

最好的工具之一是 Rails 開(kāi)發(fā)日志，它通常位于每個(gè)開(kāi)發(fā)機(jī)器上的 log/development.log 文件內(nèi)。它具有各種綜合指標(biāo)：響應(yīng)請(qǐng)求所花費(fèi)的總時(shí)間、花費(fèi)在數(shù)據(jù)庫(kù)內(nèi)的時(shí)間所占的百分比、生成視圖所花時(shí)間的百分比等。此外，還有一些工具可用來(lái)分析此日志文件，比如 development-log-analyzer。

在生產(chǎn)期間，通過(guò)查看 mysql_slow_log 可以找到很多有價(jià)值的信息。更為全面的介紹超出了本文的討論范圍，更多信息可以在 參考資料 部分找到。

其中一個(gè)最強(qiáng)大也是最為有用的工具是 query_reviewer 插件（參見(jiàn) 參考資料）。這個(gè)插件可顯示在頁(yè)面上有多少查詢?cè)趫?zhí)行以及頁(yè)面生成需要多長(zhǎng)時(shí)間。并且它還會(huì)自動(dòng)分析 ActiveRecord 生成的 SQL 代碼以便發(fā)現(xiàn)潛在問(wèn)題。例如，它能找到不使用 MySQL 索引的查詢，所以如果您忘記了索引一個(gè)重要的列并由此造成了性能問(wèn)題，那么您將能很容易地找到這個(gè)列（有關(guān) MySQL 索引的更多信息，參見(jiàn) 參考資料）。此插件在一個(gè)彈出的 <div>（只在開(kāi)發(fā)模式下可見(jiàn)）中顯示了所有這類信息。

最后，不要忘記使用類似 Firebug、yslow、Ping 和 tracert 這樣的工具來(lái)檢測(cè)性能問(wèn)題是來(lái)自于網(wǎng)絡(luò)還是資源加載問(wèn)題。

接下來(lái)，讓我們來(lái)看具體的一些 Rails 性能問(wèn)題及其解決方案。

N+1 查詢問(wèn)題

N+1 查詢問(wèn)題是 Rails 應(yīng)用程序最大的問(wèn)題之一。例如，清單 1 內(nèi)的代碼能生成多少查詢？此代碼是一個(gè)簡(jiǎn)單的循環(huán)，遍歷了一個(gè)假想的 post 表內(nèi)的所有 post，并顯示 post 的類別和它的主體。
清單 1. 未優(yōu)化的 Post.all 代碼

<%@posts = Post.all(@posts).each do |p|%> 
 <h1><%=p.category.name%></h1>
 <p><%=p.body%></p>
<%end%>
 

答案：上述代碼生成了一個(gè)查詢外加 @posts 內(nèi)的每行一個(gè)查詢。由于每查詢的負(fù)荷，這可能會(huì)成為一個(gè)很大的挑戰(zhàn)。罪魁禍?zhǔn)资菍?duì) p.category.name 的調(diào)用。這個(gè)調(diào)用只應(yīng)用于該特定的 post 對(duì)象，而不是整個(gè) @posts 數(shù)組。幸好，通過(guò)使用立即加載，我們可以修復(fù)這個(gè)問(wèn)題。

立即加載 意味著 Rails 將自動(dòng)執(zhí)行所需的查詢來(lái)加載任何特定子對(duì)象的對(duì)象。Rails 將使用一個(gè) JOIN SQL 語(yǔ)句或一個(gè)執(zhí)行多個(gè)查詢的策略。不過(guò)，假設(shè)指定了將要使用的所有子對(duì)象，那么將永遠(yuǎn)不會(huì)導(dǎo)致 N+1 的情形，在 N+1 情形下，一個(gè)循環(huán)的每個(gè)迭代都會(huì)生成額外的一個(gè)查詢。清單 2 是對(duì) 清單 1 內(nèi)代碼的修訂，它使用了立即加載來(lái)避免 N+1 問(wèn)題。
清單 2. 用立即加載優(yōu)化后的 Post.all 代碼

<%@posts = Post.find(:all, :include=>[:category]
 @posts.each do |p|%> 
 <h1><%=p.category.name%></h1>
 <p><%=p.body%></p>
<%end%>

該代碼最多生成兩個(gè)查詢，而不管在此 posts 表內(nèi)有多少行。

當(dāng)然，并不是所有情況都如此簡(jiǎn)單。處理復(fù)雜的 N+1 查詢情況需要更多的工作。那么做這么多努力值得么？讓我們來(lái)做一些快速的測(cè)試。

測(cè)試 N+1

使用清單 3 內(nèi)的腳本，可以發(fā)現(xiàn)查詢可以達(dá)到 — 多慢 — 或多快。 清單 3 展示了如何在一個(gè)獨(dú)立腳本中使用 ActiveRecord 來(lái)建立一個(gè)數(shù)據(jù)庫(kù)連接、定義表并加載數(shù)據(jù)。然后，可以使用 Ruby 的內(nèi)置基準(zhǔn)測(cè)試庫(kù)來(lái)查看哪種方式更快，快多少。
清單 3. 立即加載基準(zhǔn)測(cè)試腳本

require 'rubygems'
require 'faker'
require 'active_record'
require 'benchmark'

# This call creates a connection to our database.

ActiveRecord::Base.establish_connection(
 :adapter => "mysql",
 :host   => "127.0.0.1",
 :username => "root", # Note that while this is the default setting for MySQL,
 :password => "",   # a properly secured system will have a different MySQL
              # username and password, and if so, you'll need to
              # change these settings.
 :database => "test")

# First, set up our database... 
class Category < ActiveRecord::Base
end

unless Category.table_exists?
 ActiveRecord::Schema.define do
 create_table :categories do |t|
  t.column :name, :string
 end
 end 
end

Category.create(:name=>'Sara Campbell\'s Stuff')
Category.create(:name=>'Jake Moran\'s Possessions')
Category.create(:name=>'Josh\'s Items')
number_of_categories = Category.count

class Item < ActiveRecord::Base 
 belongs_to :category 
end

# If the table doesn't exist, we'll create it.

unless Item.table_exists?
 ActiveRecord::Schema.define do
 create_table :items do |t|
  t.column :name, :string
  t.column :category_id, :integer 
 end
 end 
end

puts "Loading data..."

item_count = Item.count
item_table_size = 10000

if item_count < item_table_size
 (item_table_size - item_count).times do
 Item.create!(:name=>Faker.name, 
         :category_id=>(1+rand(number_of_categories.to_i)))
 end
end

puts "Running tests..."

Benchmark.bm do |x| 
 [100,1000,10000].each do |size| 
 x.report "size:#{size}, with n+1 problem" do 
  @items=Item.find(:all, :limit=>size)
  @items.each do |i| 
  i.category
  end 
 end 
 x.report "size:#{size}, with :include" do 
  @items=Item.find(:all, :include=>:category, :limit=>size)
  @items.each do |i| 
  i.category
  end 
 end 
 end 
end

這個(gè)腳本使用 :include 子句測(cè)試在有和沒(méi)有立即加載的情況下對(duì) 100、1,000 和 10,000 個(gè)對(duì)象進(jìn)行循環(huán)操作的速度如何。為了運(yùn)行此腳本，您可能需要用適合于您的本地環(huán)境的參數(shù)替換此腳本頂部的這些數(shù)據(jù)庫(kù)連接參數(shù)。此外，需要?jiǎng)?chuàng)建一個(gè)名為 test 的 MySQL 數(shù)據(jù)庫(kù)。最后，您還需要 ActiveRecord 和 faker 這兩個(gè) gem，二者可通過(guò)運(yùn)行 gem install activerecord faker 獲得。

在我的機(jī)器上運(yùn)行此腳本生成的結(jié)果如清單 4 所示。
清單 4. 立即加載的基準(zhǔn)測(cè)試腳本輸出

-- create_table(:categories)
 -> 0.1327s
-- create_table(:items)
 -> 0.1215s
Loading data...
Running tests...
  user   system   total    real
size:100, with n+1 problem 0.030000  0.000000  0.030000 ( 0.045996)
size:100, with :include 0.010000  0.000000  0.010000 ( 0.009164)
size:1000, with n+1 problem 0.260000  0.040000  0.300000 ( 0.346721)
size:1000, with :include 0.060000  0.010000  0.070000 ( 0.076739)
size:10000, with n+1 problem 3.110000  0.380000  3.490000 ( 3.935518)
size:10000, with :include 0.470000  0.080000  0.550000 ( 0.573861)

在所有情況下，使用 :include 的測(cè)試總是更為迅速 — 分別快 5.02、4.52 和 6.86 倍。當(dāng)然，具體的輸出取決于您的特定情況，但立即加載可明顯導(dǎo)致顯著的性能改善。

嵌套的立即加載

如果您想要引用一個(gè)嵌套的關(guān)系 — 關(guān)系的關(guān)系，又該如何呢？ 清單 5 展示了這樣一個(gè)常見(jiàn)的情形：循環(huán)遍歷所有的 post 并顯示作者的圖像，其中 Author 與 Image 是 belongs_to 的關(guān)系。
清單 5. 嵌套的立即加載用例

@posts = Post.all 
@posts.each do |p| 
 <h1><%=p.category.name%></h1>
 <%=image_tag p.author.image.public_filename %> 
 <p><%=p.body%> 
 <%end%>

此代碼與之前一樣亦遭遇了相同的 N+1 問(wèn)題，但修復(fù)的語(yǔ)法卻沒(méi)有那么明顯，因?yàn)檫@里所使用的是關(guān)系的關(guān)系。那么如何才能立即加載嵌套關(guān)系呢？

正確的答案是使用 :include 子句的哈希語(yǔ)法。清單 6 給出了使用哈希語(yǔ)法的一個(gè)嵌套的立即加載。
清單 6. 嵌套的立即加載解決方案

@posts = Post.find(:all, :include=>{ :category=>[],
                    :author=>{ :image=>[]}} )
@posts.each do |p| 
 <h1><%=p.category.name%></h1>
 <%=image_tag p.author.image.public_filename %> 
 <p><%=p.body%> 
 <%end%>

正如您所見(jiàn)，您可以嵌套哈希和數(shù)組實(shí)量（literal）。請(qǐng)注意在本例中哈希和數(shù)組之間的惟一區(qū)別是哈?？梢院星短椎淖訔l目，而數(shù)組則不能。否則，二者是等效的。

間接的立即加載

并非所有的 N+1 問(wèn)題都能很容易地察覺(jué)到。例如，清單 7 能生成多少查詢？
清單 7. 間接的立即加載示例用例

 <%@user = User.find(5)
  @user.posts.each do |p|%>  
   <%=render :partial=>'posts/summary', :locals=>:post=>p
   %> <%end%>

當(dāng)然，決定查詢的數(shù)量需要對(duì) posts/summary partial 有所了解。清單 8 中顯示了這個(gè) partial。
清單 8. 間接立即加載 partial: posts/_summary.html.erb

 <h1><%=post.user.name%></h1>

不幸的是，答案是 清單 7 和 清單 8 在 post 內(nèi)每行生成一個(gè)額外查詢，查找用戶的名字 — 即便 post 對(duì)象由 ActiveRecord 從一個(gè)已在內(nèi)存中的 User 對(duì)象自動(dòng)生成。簡(jiǎn)言之，Rails 并不能關(guān)聯(lián)子記錄與其父記錄。

修復(fù)方法是使用自引用的立即加載?；旧?，由于 Rails 重載由父記錄生成的子記錄，所以需要立即加載這些父記錄，就如同父與子記錄之間是完全分開(kāi)的關(guān)系一樣。代碼如清單 9 所示。
清單 9. 間接的立即加載解決方案

 <%@user = User.find(5, :include=>{:posts=>[:user]})
 ...snip...

雖然有悖于直覺(jué)，但這種技術(shù)與上述技術(shù)的工作原理大致相似。但是，很容易使用這種技術(shù)進(jìn)行過(guò)多的嵌套，尤其是在體系結(jié)構(gòu)復(fù)雜的情況下。簡(jiǎn)單的用例還好，比如 清單 9 內(nèi)所示的，但繁復(fù)的嵌套也會(huì)出問(wèn)題。在一些情況下，過(guò)多地加載 Ruby 對(duì)象有可能會(huì)比處理 N+1 問(wèn)題還要緩慢 — 尤其是當(dāng)每個(gè)對(duì)象并沒(méi)有被整個(gè)樹(shù)遍歷時(shí)。在該種情況下，N+1 問(wèn)題的其他解決方案可能更為適合。

一種方式是使用緩存技術(shù)。Rails V2.1 內(nèi)置了簡(jiǎn)單的緩存訪問(wèn)。使用 Rails.cache.read、 Rails.cache.write 及相關(guān)方法，可以輕松創(chuàng)建自己的簡(jiǎn)單緩存機(jī)制，并且后端可以是一個(gè)簡(jiǎn)單的內(nèi)存后端、一個(gè)基于文件的后端或一個(gè)分布式緩存服務(wù)器。在 參考資料 部分可以找到有關(guān) Rails 內(nèi)置緩存支持的更多信息。但您無(wú)需創(chuàng)建自己的緩存解決方案；您可以使用一個(gè)預(yù)置的 Rails 插件，比如 Nick Kallen 的 cache money 插件。這個(gè)插件提供了 write-through 緩存并以 Twitter 上使用的代碼為基礎(chǔ)。更多信息參見(jiàn) 參考資料。

當(dāng)然，并不是所有的 Rails 問(wèn)題都與查詢的數(shù)量有關(guān)。

Rails 分組和聚合計(jì)算

您可能遇到的一個(gè)問(wèn)題是在 Ruby 所做的工作本應(yīng)由數(shù)據(jù)庫(kù)完成。這考驗(yàn)了 Ruby 的強(qiáng)大程度。很難想象在沒(méi)有任何重大激勵(lì)的情況下人們會(huì)自愿在 C 中重新實(shí)現(xiàn)其數(shù)據(jù)庫(kù)代碼的各個(gè)部分，但很容易在 Rails 內(nèi)對(duì) ActiveRecord 對(duì)象組進(jìn)行類似的計(jì)算。但是，Ruby 總是要比數(shù)據(jù)庫(kù)代碼慢。所以請(qǐng)不要使用純 Ruby 的方式執(zhí)行計(jì)算，如清單 10 所示。
清單 10. 執(zhí)行分組計(jì)算的不正確方式

 all_ages = Person.find(:all).group_by(&:age).keys.uniq
 oldest_age = Person.find(:all).max

相反，Rails 提供了一系列的分組和聚合函數(shù)?？梢韵袂鍐?11 所示的那樣使用它們。
清單 11. 執(zhí)行分組計(jì)算的正確方式

 all_ages = Person.find(:all, :group=>[:age]) 
 oldest_age = Person.calcuate(:max, :age)

ActiveRecord::Base#find 有大量選項(xiàng)可用于模仿 SQL。更多信息可以在 Rails 文檔內(nèi)找到。注意，calculate 方法可適用于受數(shù)據(jù)庫(kù)支持的任何有效的聚合函數(shù)，比如 :min、:sum 和 :avg。此外，calculate 能夠接受若干實(shí)參，比如 :conditions。查閱 Rails 文檔以獲得更詳細(xì)的信息。

不過(guò)，并不是在 SQL 內(nèi)能做的所有事情在 Rails 內(nèi)也能做。如果插件不夠，可以使用定制 SQL。

用 Rails 定制 SQL

假設(shè)有這樣一個(gè)表，內(nèi)含人的職業(yè)、年齡以及在過(guò)去一年中涉及到他們的事故的數(shù)量。可以使用一個(gè)定制 SQL 語(yǔ)句來(lái)檢索此信息，如清單 12 所示。
清單 12. 用 ActiveRecord 定制 SQL 的例子

sql = "SELECT profession,
       AVG(age) as average_age, 
       AVG(accident_count) 
     FROM persons 
    GROUP 
      BY profession"

Person.find_by_sql(sql).each do |row|  
 puts "#{row.profession}, " <<
    "avg. age: #{row.average_age}, " <<
    "avg. accidents: #{row.average_accident_count}"
end

這個(gè)腳本應(yīng)該能生成清單 13 所示的結(jié)果。
清單 13. 用 ActiveRecord 定制 SQL 的輸出

 Programmer, avg. age: 18.010, avg. accidents: 9
 System Administrator, avg. age: 22.720, avg. accidents: 8

當(dāng)然，這是最簡(jiǎn)單的例子。您可以自己想象一下如何能將此例中的 SQL 擴(kuò)展成一個(gè)有些復(fù)雜性的 SQL 語(yǔ)句。您還可以使用 ActiveRecord::Base.connection.execute 方法運(yùn)行其他類型的 SQL 語(yǔ)句，比如 ALTER TABLE 語(yǔ)句，如清單 14 所示。
清單 14. 用 ActiveRecord 定制非查找型 SQL

 ActiveRecord::Base.connection.execute "ALTER TABLE some_table CHANGE COLUMN..."

大多數(shù)的模式操作，比如添加和刪除列，都可以使用 Rails 的內(nèi)置方法完成。但如果需要，也可以使用執(zhí)行任意 SQL 代碼的能力。

結(jié)束語(yǔ)

與所有的框架一樣，如果不多加小心和注意，Ruby on Rails 也會(huì)遭遇性能問(wèn)題。所幸的是，監(jiān)控和修復(fù)這些問(wèn)題的技術(shù)相對(duì)簡(jiǎn)單且易學(xué)，而且即便是復(fù)雜的問(wèn)題，只要有耐心并對(duì)性能問(wèn)題的源頭有所了解，也是可以解決的。

最新評(píng)論