緩存能夠一舉兩得：通過更快地傳遞内容，緩存可以改善網站性能，同時減輕源伺服器的負擔。緩存的效率取決于内容的緩存度。這些内容可以存儲多長時間，如何檢查更新，相同的緩存内容可以發給多少使用者？
兩者中間是個有趣的待緩存對象：可能會無計劃更換，但是并非針對每位使用者（或者在用戶端通過 javascript實作個性化）的動态内容。這類内容的生成代價很高，提供過時版本又會帶來新的問題。
适合緩存的動态内容包括：
經常更新的新聞或部落格網站的首頁，每隔幾秒就有新文章釋出
最近資訊 rss
持續整合（ci）或搭建平台的進度頁面
庫存、進度或籌款計數
彩票開獎結果
月曆資料
在用戶端呈現的個人化動态内容，例如利用 cookie 資料展示的廣告内容或資料（“你好，你的名字”）
微程式緩存是一種緩存技術，将内容緩存1秒左右很短的時間。這意味着網站更新會延遲不到1秒鐘，這在很多情況下是可以接受的。
這種短暫緩存能給網站性能帶來可察覺的改觀嗎？來試試看！
測試中，vmstat 顯示造成瓶頸的原因是利用 php 生成頁面的 cpu 消耗（在 cpu 範圍的 us 一列，數值為96到98。）
熱門使用量顯示，cpu 被10個執行 php 解釋器的 apache httpd 程序占用。
這種設定本身就是問題——它限制了網站每秒鐘處理請求的數量不能超過5個，很容易遭到 dos攻擊，而通過添加 cpu 來解決這個問題意味着每年的托管費用都要增加1000美元。
利用 nginx 來加速服務隻需兩步。
在 wordpress 伺服器安裝 nginx 或 nginx plus 并進行配置，讓它接收通路流量并在内部轉發到 wordpress 伺服器：
nginx 代理伺服器配置比較簡單：
筆者還修改了 apache 配置（監聽端口号和虛拟伺服器），這樣 apache 就綁定到了 localhost:80。
你可能以為添加額外的代理伺服器會對性能造成負面影響，但是實際上性能變化可以忽略不計：
在伺服器配置中隻添加了兩條指令，nginx 或 nginx plus 就可以緩存所有可緩存的響應。帶有 200 ok 狀态碼的響應隻緩存1秒鐘。
筆者再次運作基準測試時，看到了性能顯著提升：
緩存進展順利，筆者驗證了内容的确是每秒更新的（是以永不過時），但是未曾預料到的情況發生了。你會發現處理時間的标準偏差很大（141.5毫秒）。cpu 使用率還是100%（用 vmstat 測量），熱門使用量顯示有10個活躍的 httpd 程序。
筆者還從 nginx plus 的活動檢測控制台找到進一步的線索。測試前：
測試後：
控制台報告顯示，nginx 在測試期間處理了18032條請求（ab 彙報的18022條請求，以及基準在30秒結束時突出的10條請求）。但是，nginx 轉發了150條請求到上遊伺服器，在緩存内容1秒鐘的情況下，這比我們期望的30秒測試應有的請求數多得多。
怎麼回事？為什麼 cpu 使用率很高，緩存更新比預期數字更大？
這是因為每次緩存條目過期時，nginx 就會停止使用它。nginx 将所有請求都轉發給上遊 wordpress 伺服器，直到它收到響應，可以用新内容來緩存。
這導緻了 wordpress 伺服器收到的請求經常激增到10條。這些請求會占用 cpu，比緩存響應的請求延遲更多，這就解釋了測試結果中的高标準差。
筆者想要的政策很清晰：需要在確定緩存内容最新的情況下，盡可能少地向上遊源伺服器轉發請求。在緩存内容不斷更新的前提下，筆者願意從緩存擷取舊的（延後1到2秒）響應。要實作這一目标，需要添加兩條指令：
加上之前已經添加的緩存指令，筆者得到如下伺服器配置：
基準測試結果的變化十分驚人。每秒鐘的請求數量從600跳躍到接近2200：
cpu 使用率也低多了（注意 cpu 下面 id 一欄的空閑時間）：
資料傳輸率（121379.72千位元組/秒，或121兆位元組每秒）相當于0.97千兆，是以該測試受網絡限制。cpu 平均使用率為66%，該伺服器的峰值性能應該大概為2185/0.66 = 3300 個請求/秒。
另外，關注 ab 報告的連續響應時間（标準偏差隻有8.1毫秒），以及操作面闆顯示的30秒測試中轉發給上遊伺服器的請求數量很少（16）：
為什麼隻有16條請求？我們知道緩存到1秒鐘時會清零，這個更新過程最多需要0.661秒（從 ab 結果來看），是以可以推測，更新頻率不會快于每1.66秒一次。在30秒鐘的時間之外，隻會收到最多18（30/1.66）條請求。
本文簡單展示了在短時間内緩存動态内容可能帶來的好處，以及 nginx plus 的活動監測資料在調整和診斷緩存配置時的用處。如果你想在生産環境中使用微程式緩存，筆者建議你建立并測試一個更為複雜的緩存規則，針對更長時間内的微程式緩存動态和靜态内容。
要想了解更多資訊，請查閱以下資源：