當然，也有一些機構的應用程序不能在單獨一臺或少數幾臺服務器上運行。所要執行的任務極為龐大復雜，沒有單獨的服務器能滿足這一需求。但是，有這類需求的機構已顯著地減少。
通過本文你會了解到：系統性能與可擴張性測試重要性的下滑與其帶來的有限回報，為何會降低你安排這些活動的優先級。
個人性能記錄
我還清楚地記得我編寫的一個性能測試應用程序。這是一個旨在同時閱讀八臺電話交換機的輸入信號的程序。每部交換機以9 600波特的速率與應用程序進行數據通信。
應用程序必須驗證記錄格式，將有效記錄與無效記錄分別寫入兩個文件。它的另一任務是在網絡發生故障時，將記錄上述文件的網絡共享文件轉移到本地驅動器上，并在網絡恢復時將文件返回過去。
此系統在一臺安裝DOS操作系統的25兆赫80486SX計算機上運行。如果不發生故障，它可以全速處理所有八臺交換機。在網絡故障期，它的最大負荷也達到五臺。這一能力已超出它能夠全速支持3到4臺交換機的設計目標。那樣，公司處理數據流的能力會在當前基礎上增加數倍。
由于錯誤引起的額外處理負擔會產生連鎖反應，使系統迅速退化。喪失一個特性就會產生額外的處理負擔，這樣又會使其它的特性喪失。
如果系統不能正常運行，收入就會降低，因此有必要測試系統的性能。但是，即使那樣，硬件的性能也會偏離普通公司的性能目標。
為何要做性能測試？
進行性能測試有兩個原因：一是為了保證系統能夠滿足公司當前或短期的計劃需求。也就是說，要確定能夠從當前的系統中獲得最大的性能。
第二個原因是：為了支持更大的負載，要就何時對系統進行改造做出規劃。這包括重新編寫解決方案片斷、重建解決方案或添置更多的硬件。這樣，進行性能測試就有助于了解：要想超越現有的系統性能，我們該做出哪些努力。
何為性能測試？
談論性能測試時，我們并不僅僅是談論性能測試本身。相反，我們談論的是響應速度、處理能力與可擴充性。這三項指標之間關系密切，每一項都不能孤立起來進行評估。
響應速度很容易量化。任何人用一塊秒表就可以迅速地測量出某一程序的響應速度。當然，甚至簡單的自動化測試方法還更為精確。不過，事實上，某一程序的響應速度是性能測試的最基本的組成部分，即使在處理能力最低的情況下，也可以進行直接觀測。發出請求到產生響應，這一過程所耗費的時間即為系統的響應速度。
處理能力是指系統在同一時間內所能處理的業務量大小。不同的業務類型對處理能力有特別的限制。某一系統每秒可能只能完成20宗業務。不管你給系統多少業務，在指定的時間內，它只能完成其最大處理能力內的業務量。
響應速度測量完成一宗業務所需的時間（秒）。例如，假定測量的響應速度為每宗業務3秒。處理能力則正好相反，它測量每秒處理的業務量。結合起來說，如果系統每秒最多可完成20宗業務，而每宗業務的響應速度為3秒，那么在任何時間，系統都同時在處理60宗業務。
響應速度與處理能力關系密切的一個原因是：系統處理的業務數量增加，則系統的響應速度就會降低。過去只花不到一秒就可完成的業務現在要花兩到三秒，甚至更長時間。更讓人沮喪的是，一般如果系統所接受的業務量超過某一速率，總體的處理能力就會下降。如果系統每秒能夠處理20宗業務，而業務以每秒25宗的速率進入系統，則系統的總體業務處理能力可能會下降到17宗每秒。正因為這樣，當我所編寫的交換機閱讀程序開始失去更多的特性時，也發生了這種情況。由額外業務引發的額外處理負擔開始引發超時、重發及其它降低總體處理能力的后果。
可擴充性測量應用程序所能擴張的程度。一旦決定了最大處理能力，下一步就要決定：在環境發生變化的情況下，處理能力可進行多大程序的擴展�？蓴U充性與瓶頸直接相關。瓶頸是已達到最大處理能力的系統的一部分，它制約系統達到更好的性能。在直接與瓶頸相關時，可擴充性選項一般十分有效。瓶頸一般分為以下幾類：處理器、內存、磁盤或網絡速度。
為了獲得有效的可擴充性，你首先必須鑒別限制處理能力的瓶頸，并著手消除此瓶頸。例如，如果瓶頸為處理器，就要進行試驗來評估增加其它處理器的效果。雖然很少有人期望資源成倍增長，處理能力也成倍增長，但如果不存在其它瓶頸，處理能力增加80%應該是合理的。
只有當瓶頸限制系統的性能時，它們才會變得明顯起來。如果處理器限制了系統的處理能力，就很難覺察到其實所安裝的內存也只能支持另外10%的業務處理能力。實際情況是，發現一個瓶頸并不一定能完成鑒別可擴充性選項的目的。一般來說，我們有必要真實展示提議的可擴充性選項的性能，以證明取得的實際改善。
這就是性能測試的主要矛盾之處。要正確進行性能測試，你得需要你所測試的硬件，在那種情況下，你實際已經購買了它。
評估性能
如今，大多數的應用程序并不需要超出一臺單獨系統處理能力的性能。例如，微軟估計，一臺運行ISA的雙處理器2.4GHz英特爾奔4服務器每秒能夠對30至42兆的SSL流量進行加密。假如大多數機構連接互聯網所使用的只是每秒1.544兆的標準T1（D1，如果你喜歡）線路，那么系統處理能力與平均需求之間就存在巨大的差距。然而，多數機構只專注于讓計算機執行SSL加密與其它一些大家熟知的困難任務，很少有人意識到系統處理能力與他們所討論的工作負載之間的差距。
討論主要集中于一種或一組要消耗更多時間的技巧。例如，在.NET中應用反射（reflection）來處理對象比直接調用對象要花費更多的時間。（反射是在運行時間訪問元數據的一種機制。）這是事實。但是，盡管反射要比直接調用方法多花幾倍的時間，它仍然沒有觸及許多應用程序的有效處理時間的表層。
同樣，由于要耗費大量的處理器能力，我們也放棄了處理異常的包裝與重扔（wrap and rethrow）方法。因為要經過很長時間才能找到合適的處理器，一般來說異常處理十分昂貴。針對直接由錯誤引起的底層異常，包裝與重扔（wrap and rethrow）技巧可能會潛在產生一些或更多異常。對處理器來說，這可能要比單獨的異常要昂貴數百倍。但是，這種認識忽略了這樣一個事實：即異常其實（或至少應該）極少發生，而且通過包裝與重扔（wrap and rethrow）技巧獲得的信息對解決問題相當有益。
另一個提到性能，且性能在這里有一定價值的地方是存儲過程（微軟SQL服務器數據庫中）。一些機構要求為每個表格訪問建立存儲過程，但并不是因為存儲過程所帶來的安全利益，而是專注于它所獲得的性能改善。然而，在大多數情況下，應用存儲過程對性能并沒有多大的改善。此過程中省略的部分（編輯與查詢優化）在SQL中十分高效，因此用不了多少時間。
針對改善許多中型與大型機構的系統性能的應用程序不在少數。但意識到性能的重要性，因而浪費資源，反而會造成性能問題。這些情況大多與編寫可靠的代碼有關，而不在于應用哪種技巧。
低廉的硬件
有可能進行性能測試并將其做好嗎？一般來說，性能測試昂貴、麻煩而又費時，而且很少會產生投資回報。對大多數機構來說，要提高性能，增加更大的內存、添置另一臺處理器或服務器可能是更為方便低廉的方式。
同樣，如果集中于影響總體性能（應用）的次要項目，我們可能會錯誤地以設計理念為中心，花費了大量的開發時間，但性能卻沒有多大改善。硬件也不貴，那就應用它吧！說這樣的話真是讓人痛苦！
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
