為了獲得有效的可擴充性，你首先必須鑒別限制處理能力的瓶頸，并著手消除此瓶頸。例如，如果瓶頸為處理器，就要進行試驗來評估增加其它處理器的效果。雖然很少有人期望資源成倍增長，處理能力也成倍增長，但如果不存在其它瓶頸，處理能力增加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/
