性能分析與調優的原理

最近一直糾結性能分析與調優如何下手，先從硬件開始，仍是先從代碼或數據庫。從操做系統（CPU調度，內存管理，進程調度，磁盤I/O）、網絡、協議（HTTP， TCP/IP ），仍是從應用程序代碼，數據庫調優，中間件配置等方面入手。

　　單一個中間件又分web中間件（apache 、IIS），應用中間件（tomcat 、weblogic 、webSphere ）等，雖然都是中間件，每同樣拎出來往深了學都不是一朝一夕之功。但調優對於每一項的要求又不只僅是「知道」或「會使用」這麼簡單。起碼要達到「如何更好的使用」。

　　常看到性能測試書中說，性能測試不僅僅是性能測試工程師一我的的事兒。須要DBA 、開發人員、運維人員的配合完成。可是在很多狀況下性能測試是由性能測試人員獨立完成的，退一步就算由其它人員的協助，瞭解系統架構的的各個模塊對於自身的提升也有很大幫助，同進也更能獲得別人的尊重。

　　再說性能調優以前，咱們有必要再提一下進行測試的目的，或者咱們進行性能測試的初衷是什麼？

　　能力驗證：驗證某系統在必定條件具備什麼樣的能力。

　　能力規劃：如何使系統達到咱們要求的性能能力。

　　應用程序診斷：好比內存泄漏，經過功能測試很難發現，但經過性能測試卻很容易發現。

　　性能調優：知足用戶需求，進一步進行系統分析找出瓶頸，優化瓶頸，提升系統總體性能。

　　

　　通常系統的瓶頸                                                                                          

　　性能測試調優須要先發現瓶頸，那麼系統通常會存在哪些瓶頸：

　　硬件上的性能瓶頸：

　　通常指的是CPU、內存、磁盤I/O 方面的問題，分爲服務器硬件瓶頸、網絡瓶頸（對局域網能夠不考慮）、服務器操做系統瓶頸（參數配置）、中間件瓶頸（參數配置、數據庫、web服務器等）、應用瓶頸（SQL 語句、數據庫設計、業務邏輯、算法等）。

　　應用軟件上的性能瓶頸：

　　通常指的是應用服務器、web 服務器等應用軟件，還包括數據庫系統。

　　例如：中間件weblogic 平臺上配置的JDBC鏈接池的參數設置不合理，形成的瓶頸。

　　應用程序上的性能瓶頸：

　　通常指的是開發人員新開發出來的應用程序。

　　例如，程序架構規劃不合理，程序自己設計有問題（串行處理、請求的處理線程不夠），形成系統在大量用戶方位時性能低下而形成的瓶頸。

　　操做系統上的性能瓶頸：

　　通常指的是windows、UNIX、Linux等操做系統。

　　例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大下降，從而致使行爲的響應時間大大增長，這時認爲操做系統上出現性能瓶頸。

　　網絡設備上的性能瓶頸：

　　通常指的是防火牆、動態負載均衡器、交換機等設備。

　　例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將後續的交易請求發送到其餘負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相應的做用，這時能夠認爲網絡瓶頸。

　　性能測試出現的緣由及其定位十分複雜，這裏只是簡單介紹常見的幾種瓶頸類型和特徵，而性能測試所須要作的就是根據各類狀況因素綜合考慮，而後協助開發人員\DBA\運維人員一塊兒定位性能瓶頸。

通常性能調優步驟                                                                                      

　　通常性能問題調優的步驟：

　　步驟一：肯定問題

　　應用程序代碼：在一般狀況下，不少程序的性能問題都是寫出來的，所以對於發現瓶頸的模塊，應該首先檢查一下代碼。

　　數據庫配置：常常引發整個系統運行緩慢，一些諸如oracle 的大型數據庫都是須要DBA進行正確的參數調整才能投產的。

　　操做系統配置：不合理就可能引發系統瓶頸。

　　硬件設置：硬盤速度、內存大小等都是容易引發瓶頸的緣由，所以這些都是分析的重點。

　　網絡：網絡負載太重致使網絡衝突和網絡延遲。

　　步驟二：肯定問題

　　當肯定了問題以後，咱們要明確這個問題影響的是響應時間吞吐量，仍是其餘問題？是多數用戶仍是少數用戶遇到了問題？若是是少數用戶，這幾個用戶與其它用戶的操做有什麼不用？系統資源監控的結果是否正常？CPU的使用是否到達極限？I/O 狀況如何？問題是否集中在某一類模塊中？ 是客戶端仍是服務器出現問題？ 系統硬件配置是否夠用？實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？

　　經過這些分析及一些與系統相關的問題，能夠對系統瓶頸有更深刻的瞭解，進而分析出真正的緣由。

　　步驟三： 肯定調整目標和解決方案

　　得高系統吞吐理，縮短響應時間，更好地支持併發。

　　步驟四：測試解決方案

　　對經過解決方案調優後的系統進行基準測試。（基準測試是指經過設計科學的測試方法、測試工具和測試系統，實現對一類測試對象的某項性能指標進行定量的和可對比的測試）

　　步驟五：分析調優結果

　　系統調優是否達到或者超出了預約目標？系統是總體性能獲得了改善，仍是以系統某部分性能來解決其餘問題。調優是否能夠結束了。

　　最後，若是達到了預期目標，調優工做就基本能夠結束了。

　　下面算是一個技巧，如面試官問到一個性能問題假設，我不知道性能問題出在哪兒時，能夠按照這個思路回答^_^

　　• 查找瓶頸時按如下順序，由易到難。

　　服務器硬件瓶頸---〉網絡瓶頸（對局域網，能夠不考慮）---〉服務器操做系統瓶頸（參數配置）---〉中間件瓶頸（參數配置，數據庫，web服務器等）---〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）

　　注：以上過程並非每一個分析中都須要的，要根據測試目的和要求來肯定分析的深度。對一些要求低的，咱們分析到應用系統在未來大的負載壓力（併發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。

　　• 分段排除法 頗有效

　　性能測試調優應該注意的要點：

　　要點1： 在應用系統的設計開發過程當中，應始終把性能放在考慮的範圍內。    
　　要點2： 肯定清晰明確的性能目標是關鍵。    
　　要點3： 必須保證調優後的程序運行正確。    
　　要點4： 系統的性能更大程度上取決於良好的設計，調優技巧只是一個輔助手段。    
　　要點5： 調優過程是迭代漸進的過程，每一次調優的結果都要反饋到後續的代碼開發中去。    
　　要點6： 性能調優不能以犧牲代碼的可讀性和可維護性爲代碼。

　　本文只介紹了一些性能調優的要關注的東西以及性能調優的通常要點。並無具體說如何對系統的每一個部件進行調優，如何要細說也不是一兩書能說清的，對知識面的要求也很是高，是我目前的能力沒法觸摸的。

　　這裏作個總結：

　　《性能測試知多少》系列基本完結，雖然時間拉得比較長，但我沒有把它給太監。雖然內容都在空談性能測試理論知識，但我認爲這些東西對於你從事性能測試工做必不可少。固然，我在「 jmeter基礎 」 與「 loadrunner 技巧 」 中講解兩個性能測試工具的使用。

　　若是個人這些文章對於想了解和學習性能的同窗帶來一絲的幫助，我將很是開心。我不是高手，只是和你一塊兒熱愛測試技術的初學者，只是比較喜歡總結；也時常爲前途迷茫，但我知道只要斷去學習，路就在前方。我後面會整理性能調優的相關文章。

 

 

 

 

 

 

動態的 Web 應用程序可以存儲大量信息，讓用戶可以經過熟悉的界面當即訪問這些信息。可是，隨着應用程序愈來愈受歡迎，可能會發現對請求的響應速度沒有之前那麼快了。 開發人員應該瞭解 Web 應用程序處理 Web 請求的方式，知道在 Web 應用程序開發中能夠作什麼，不能作什麼，這有助於減小往後的麻煩。

靜態的 Web 請求（好比圖 1 所示的請求）很容易理解。客戶機鏈接服務器（一般經過 TCP 端口 80），使用 HTTP 協議發出一個簡單的請求。

圖 1. 客戶機經過 HTTP 請求靜態的文件

服務器解析這個請求，把它映射到文件系統上的一個文件。而後，服務器向客戶機發送一些描述有效負載（好比網頁或圖像）的響應頭，最後向客戶機發送文件。

在 上面的場景中可能出現幾個瓶頸。若是請求的變化很大，致使沒法有效地使用操做系統的磁盤緩存，那麼服務器的磁盤會很忙，到了某種程度以後，就會減慢整個過 程。若是爲客戶機提供數據的網絡通道飽和了，就會影響全部客戶機。可是，除了這些情況以外，「接收請求，發送文件」 過程仍是至關高效的。

通 過作一些假設，能夠大體體會靜態服務器的性能。假設一個請求的服務時間是 10ms（主要受到磁頭尋道時間的限制），那麼大約每秒 100 個請求就會使磁盤接近飽和（10msec/request / 1 second = 100 requests/second）。若是要發送 10K 的文檔，就會產生大約 8mbit/sec 的 Web 通訊流（100 requests/second * 10 KBytes/request * 8bits/byte）。若是能夠從內存緩存中獲取文件，就能夠下降平均服務時間，所以增長服務器每秒可以處理的鏈接數。若是您有磁盤服務時間或平均請求 延時的真實數據，能夠把它們放進上面的算式，從而計算出更準確的性能估計值。

既然服務器的處理容量是平均請求服務時間的倒數，那麼若是服務時間加倍，服務器的處理容量（每秒處理的鏈接數）就會減半。請記住這一點，下面看看動態應用程序的狀況。

動態應用程序的流程依賴於應用程序的具體狀況，可是通常狀況下與圖 2 類似。

圖 2. 客戶機經過 HTTP 請求動態頁面

與前一個示例中的客戶機同樣，圖 2 中的客戶機首先發出一個請求。靜態請求和動態請求之間實際上沒什麼差別（有時候 .php 或 .cgi 等擴展名可能意味着動態請求，可是它們可能引發誤解）。如何處理請求是由 Web 服務器決定的。

在 圖 2 中，請求被髮送到一個應用服務器，好比運行一個 Java™ 應用程序的 Solaris 系統。應用服務器執行一些處理，而後向數據庫查詢更多的信息。獲得這些信息以後，應用服務器生成一個 HTML 頁面，這個頁面由 Web 服務器轉發給客戶機。所以，這個請求的服務時間是幾個部分的總和。若是數據庫訪問花費 7ms，應用服務器花費 13ms，Web 服務器花費 5ms，那麼網頁的服務時間就是 25ms。根據前面介紹的倒數規則，各個組件的容量分別是每秒 14二、77 和 200 個請求。所以，瓶頸是應用服務器，它使這個系統每秒只能處理 77 個鏈接；超過這個數量以後，Web 服務器被迫等待，鏈接開始排隊。

但 是，必定要注意一點：由於系統每秒只能分派 77 個鏈接，而一個鏈接須要的處理時間是 25ms，因此並不是每一個應用程序用戶的請求都可以在 25ms 內獲得處理。每一個組件每次只能處理一個鏈接，因此在高峯負載下，請求不得不等待 CPU 時間。在上面的示例中，考慮到排隊時間和 25ms 的處理時間，平均請求服務時間最終會超過 1.1 秒。關於解決這些排隊問題的更多信息，請參見 參考資料。

經過這些示例能夠得出如下結論：

• 在用戶發出請求和得到最終頁面之間的步驟越多，整個過程就越慢，系統容量就越低。

• 隨着頁面請求速率的增長，這種效應會愈來愈顯著。

• 在項目開始時作出的體系結構決策也會影響站點處理負載的能力。

本文的其他部分將深刻討論這些問題。

用於動態站點的 N 層體系結構

應用程序（包括 Web 應用程序）的體系結構經常按照層來描述。靜態站點能夠被看做只有一層 —— Web 服務器。若是用 Web 服務器運行某種腳本語言（好比 PHP），從而鏈接數據庫，那麼這能夠看做兩層。前一節中的示例有三層，即前端 Web 服務器、應用服務器和數據庫。

一 個軟件也可能由多層組成，這取決於您談話的對象。例如，PHP 腳本可能使用一個模板引擎把業務邏輯與表示分隔開，它能夠被看做單獨的兩層。Java 應用程序可能經過 Java servlet 執行表示任務，servlet 經過與 Enterprise Java Bean (EJB) 通訊執行業務邏輯，EJB 經過鏈接數據庫獲取更多信息。所以，換一個角度來看，三層體系結構多是另外一副樣子，尤爲是在涉及不一樣的工具集時。

常見的體系結構

儘管應用程序的體系結構各不相同，可是有一些常見的體系結構趨勢。在通常狀況下，應用程序須要四個功能層：

• 客戶機層

• 表示層

• 業務邏輯層

• 數據層

在 Web 應用程序中，客戶機層由 Web 瀏覽器處理。瀏覽器顯示 HTML 並執行 Javascript（以及 Java applet、ActiveX 或 Flash applet），從而向用戶顯示信息和收集用戶信息。表示層是從服務器到客戶機的接口，它負責控制輸出的格式，讓輸出能夠在客戶機上顯示。業務邏輯層實施 業務規則（好比計算和工做流），從而驅動應用程序。最後，數據訪問層是持久化的數據存儲，好比數據庫或文件存儲。

大多數應用程序須要全部這四層的功能，儘管它們可能不須要明顯完整地實現這些層。

另外一種流行的體系結構是 Model-View-Controller，這是一種用於分隔應用程序組件的模式。在 MVC 模式中，模型封裝業務邏輯層，並與框架一塊兒封裝數據層。視圖負責處理髮送給客戶機的數據表示。控制器的做用是控制應用程序流程。

層的容量擴展

擴 展 Web 應用程序的容量意味着讓它可以處理更多的通訊流。容量擴展的一個方面是如何根據需求部署硬件。另外一個方面是應用程序如何響應新的硬件環境。從概念上說，在 出現性能問題時，每每首先想到使用功能更強的服務器；可是應用程序自己極可能形成其餘瓶頸。把應用程序劃分爲一系列層有助於收縮問題的範圍，能夠簡化容量 擴展。

如今先不考慮應用程序瓶頸。擴展應用程序的硬件一般有兩種方式：水平擴展和垂直擴展。水平擴展意味着在一層中添加更多的服務器。在前面的示例中，應用服務器的瓶頸把請求速率限制在每秒 77 個請求，經過添加第二個應用服務器並在兩個服務器之間共享負載，可能能夠解決此問題。這會把理論容量提升到每秒 154 個請求，瓶頸位置就會轉到數據庫。

另外一方面，垂直擴展意味着使用功能更強的計算機。可使用功能更強的計算機運行應用服務器的兩個實例，或者更快地處理請求。

初 看上去，您可能會徹底排除垂直擴展方式，由於購買多臺小型計算機一般比不斷購買更高級的服務器便宜。可是，在許多狀況下，垂直擴展是更好的方法。若是您有 經過邏輯分區 (LPAR) 支持硬件分區的 IBM® Power® 服務器，就能夠把空閒的容量添加到應用服務器層。

應用程序的需求也可能促使您選擇垂直擴展。在一臺服務器上很容易經過共享內存段共享用戶的會話狀態。若是使用兩臺服務器，就須要經過其餘方式共享狀態，好比數據庫。數據庫訪問比內存訪問慢，因此兩臺服務器的處理速度達不到一臺服務器的兩倍。

數據庫是另外一個經常適合使用垂直擴展的場合。讓數據集跨越不一樣的服務器須要在應用程序層作大量工做，好比跨兩個數據庫聯結列並確保數據是一致的。使用更強大的數據庫服務器要容易得多，並且不須要經過從新構建應用程序來支持分散的數據。

把 Web 應用程序建模爲隊列

根據前面對應用程序體系結構的討論能夠看出，Web 請求會經過多個階段，每一個階段花費必定的執行時間。請求排隊經過每一個步驟，完成一個步驟以後，再排隊進入下一個步驟。每一個步驟很像人們在商店裏排隊結賬的狀況。

能夠把 Web 應用程序建模爲一系列步驟（稱爲 「隊列」）。應用程序的每一個組件都是一個隊列。建模爲一系列隊列的典型 WebSphere 應用程序如圖 3 所示。

圖 3. 建模爲排隊網絡的 WebSphere® 應用程序

圖 3 顯示請求等待 Web 服務器處理它們，而後等待 Web 容器，依此類推。若是進入某個隊列的請求速率超過了此隊列處理請求的速率，請求就會彙集起來。當出現請求彙集時，服務時間是不可預測的，用戶會察覺到瀏覽器會話延遲。圖 3 中的隊列表明最糟糕的狀況，由於 Web 服務器能夠本身處理一些請求，即不須要訪問數據庫。

隊 列在 UNIX® 環境中很常見。當應用程序發出磁盤請求的速率快於磁盤返回數據的速率時，操做系統會讓磁盤請求排隊，還可能調整請求的次序以下降尋道時間。另外一個隊列是運 行隊列，其中包含等待運行的進程的有序列表。應用程序會等待輪到它們使用某些有限的資源（好比 CPU）。

所以，隊列調優是一種平衡的藝術。隊列過小，就會在仍然有富餘容量的狀況下拒絕用戶。隊列太大，就會試圖爲過多的用戶提供服務，致使性能不好。

導 致狀況更復雜的另外一個因素是，這些排隊位置並非無成本的。保留排隊位置會致使內存開銷，對於應用服務器，這會與正在處理請求的線程爭用內存。所以，在一 般狀況下，在應用服務器上排隊並非好方法。推薦的方法是在應用服務器以前（好比在 Web 服務器上）排隊。這意味着 Web 服務器要保持與 Web 客戶機的鏈接，並在應用服務器空閒時發出請求。應用服務器只需處理它可以及時派發的請求。

IBM 的文檔中推薦了 Web 應用程序佈局方法和各類隊列的調優方法。可是注意，IBM 建議應該避免在 WebSphere 中排隊。這意味着應該把發送給 WebSphere 應用服務器的請求速率控制在可以當即處理的範圍內。Web 服務器（或 Web 服務器前面的代理服務器）應該限制過多的鏈接，讓它們等待處理。這確保負載比較重的應用服務器隊列可以把時間花在爲有限的請求提供服務上，而不是試圖同時 爲全部請求提供服務。

針對開發人員的提示

做爲開發人員，應該按照一些通常原則提升應用程序的可伸縮性。這些原則能夠應用於大多數 Web 應用程序。

度量設施

應 用程序應該以某種方式向收集系統提供度量值（即便收集系統僅僅是日誌文件）。這些度量值包括訪問應用程序中某個函數的頻率或處理一個請求花費的時間等。這 並不會使應用程序運行得更快，可是有助於瞭解應用程序爲何會變慢以及代碼的哪些部分花費的時間最長。瞭解何時調用某些函數，這有助於把在系統上觀察 到的現象（好比 CPU 忙或磁盤活動量高）與應用程序中的活動（好比上傳圖像）聯繫起來。

可以瞭解站點上發生的狀況，這是擴展站點容量的關鍵。您認爲不夠優化的代碼部分可能不會形成問題。只有經過適當的度量，才能發現真正的瓶頸。

會話

Web 在本質上是無狀態的。用戶發出的每一個請求都獨立於之前的請求。可是，應用程序經常是有狀態的。用戶必須登陸應用程序以證實本身的身份，在訪問站點期間可能 要維護購物車的狀態，還可能要填寫供之後使用的我的信息。跟蹤會話是一種成本很高的操做，尤爲是在涉及多個服務器的狀況下。

在單 一服務器上運行的 Web 應用程序能夠把會話信息放在內存中，在服務器上運行的任何 Web 應用程序實例均可以訪問共享內存。經常會給用戶分配一個標誌，這個標誌標識內存中的會話。考慮一下在涉及第二個應用服務器時會發生什麼。若是用戶的第一個 請求發送給一個服務器，第二個請求發送給另外一個服務器，那麼會存在兩個單獨的會話，它們並不相同。

此問題的經常使用解決方案是，把會話存儲在數據庫而不是內存中。這種方法致使的問題是，對於每一個請求，須要增長數據庫讀操做，還可能涉及數據庫寫操做。每一個 Web 應用服務器都須要這個數據庫。

一個解決方案是，只在須要會話的地方使用會話。應用程序並不爲每一個請求裝載會話，而是隻在須要會話時裝載會話。這會減小對後端數據庫的請求數量。

另 一個方法是加密會話數據並把它發送回客戶機，這樣就不須要在本地存儲會話。在用戶的 cookie 中可以存儲的數據量是有限的，可是 RFC 2109 規定客戶機應該可以爲每一個域名存儲至少 20 個 cookie，每一個 cookie 至少能夠保存 4K 字節的數據。

若是發現用數據庫存儲的會話是性能瓶頸，並且沒法消除它們，那麼應該考慮把它們分散到單獨的數據庫，甚至是多個數據庫。例如，能夠在一個數據庫中存儲偶數的會話 ID，在另外一個數據庫中存儲奇數的會話 ID。

緩存

與其餘部分相比，應用程序的某些部分會更頻繁地修改數據。新聞網站可能每月只修改頂級分類列表一次。所以，對於每一個請求都經過查詢數據庫獲取最新的分類列表是很浪費的。一樣，包含新聞稿的頁面在其整個生命週期中可能只修改一兩次，因此不須要爲每一個請求從新生成它。

緩存意味着把處理成本很高的請求的結果存儲起來，供之後使用。能夠緩存分類列表或整個頁面。

在考慮緩存時，問本身一個問題：「這些信息必須是最新的嗎？」 若是不是這樣，就能夠考慮使用緩存。在新聞最初出現時，可以及時改變新聞稿可能很重要；可是在之後，每分鐘檢查一次修改並經過緩存提供頁面，就足夠了。

一種補充方法是，當底層數據改變時，讓緩存的數據項失效。若是修改了新聞稿，在保存它時能夠刪除緩存的版本。對於下一個請求，因爲沒有緩存的版本，因此會生成新的數據項。

在使用緩存時，必須注意在緩存項過時或被刪除時發生的狀況。若是有許多請求在請求緩存項，那麼在緩存項過時時，會爲許多用戶從新生成緩存項。爲了解決這個問題，能夠只爲第一個請求從新生成緩存，而其餘用戶使用過期的版本，直到新的緩存項可用爲止。

memcached 是一種流行的分佈式內存緩存系統，在 UNIX 環境中部署的許多應用程序都使用它。服務器運行 memcache 守護進程的實例，這些進程分配一塊能夠經過一種簡單的網絡協議訪問的 RAM。但願在 memcache 中存儲或獲取數據的應用程序首先對鍵進行散列計算，這告訴它們應該使用 memcache 池中的哪一個服務器。而後，經過鏈接這個服務器檢查或存儲數據，這比磁盤或數據庫訪問快得多。

在尋找應該緩存的數據時，還應該考慮是否確實須要直接提供這些信息。須要在每一個頁面上顯示用戶的購物車嗎？只顯示總金額怎麼樣？或者只顯示一個簡單的連接 「view the contents of your cart」。

Edge-Side Includes (ESI) 是一種標記語言，能夠用它把網頁劃分爲單獨的可緩存的實體。應用程序負責生成包含 ESI 標記的 HTML 文檔，還負責生成組件。Web 應用程序前面的代理緩存根據各個部分從新組裝最終的文檔，負責緩存一些組件併爲其餘組件發出請求。清單 1 給出一個 ESI 文檔示例。

清單 1. ESI 示例

 

<html> <head> </head> <body> <p>This is static content</p> <esi:include src="/stories/123" /> <p>The line above just told the proxy to request /stories/123 and insert   it in the middle of the page </p> </body> </html>

 

 

儘管這個示例很是簡單，可是 清單 1 說明了如何把兩個文檔拼接在一塊兒，這兩個文檔有本身的緩存規則。

異步處理

還 有一個問題與 「這些信息必須是最新的嗎？」 相關：「必須在處理完請求時更新這些信息嗎？」 在許多狀況下，能夠獲取用戶提交的數據並把處理延後幾秒，而不須要在處理信息時讓用戶一直等待裝載頁面。這稱爲異步處理。一種經常使用方法是，讓應用程序把數 據發送給一個消息隊列，好比 IBM WebSphere MQ，等待到資源可用時處理數據。這樣就能夠當即把一個頁面返回給用戶，儘管數據處理的結果仍是未知的。

請考慮一個電子商務應用 程序，用戶會在這個程序中提交訂單。當即返回信用卡檢驗結果多是很重要的，可是不須要讓訂單系統立刻確認訂單的全部內容都是有效的。能夠把訂單放進一個 隊列中等待處理，這可能會在幾秒內發生。若是發生了錯誤，能夠經過電子郵件通知用戶，若是用戶仍然在網站上，甚至能夠把錯誤通知插入他的會話。另外一個示例 是報告。不須要讓用戶一直等待生成報告，而是能夠返回 「please check the reports page in a few minutes」 消息，同時在另外一臺服務器上異步地生成報告。

結束語

應用程序經常採用分層方式編寫。表示邏輯與業務邏輯分隔開，業務邏輯又與持久化存儲分隔開。這種方式能夠提升代碼的可維護性，可是也會致使一些開銷。在擴展應用程序的容量時，應該瞭解數據在分層環境中的流動並尋找出現瓶頸的位置。

緩存和異步處理等技術能夠重用之前的結果或把工做轉移到另外一臺計算機上，從而下降應用程序的工做負載。在應用程序中提供度量設施，有助於及時瞭解 「熱點」。

應用服務器環境的工做方式與排隊網絡很類似，必定要仔細地管理隊列的大小，確保一層不會對另外一層施加過大的壓力。IBM 建議儘量在應用服務器以前排隊，好比在外部 Web 服務器或代理服務器上。

僅僅靠投入更多的硬件，不多可以有效地擴展應用程序的容量。經常須要綜合應用這些技術，才能讓新的硬件發揮做用。