性能測試基礎知識－性能的規劃與實現

性能的規劃與實現
    一個不能按意愿執行的程序是沒有用處的。每個程序都必須滿足某組用戶（有時會是一組很大且需求各不相同的用戶）的需求。如果程序的性能確實不能滿足那些用戶中很大一部分用戶的需求，則不會使用這個程序。一個不被使用的程序是不能實現預期功能的。

    這種情況對經許可的軟件包和用戶編寫的應用程序是確實存在的，盡管大多數軟件包開發者意識到低性能的影響，并盡力提高程序的運行速度。不幸的是，他們不能預測程序要經歷的所有環境和用途。讓程序具有可接受性能的最終職責就落在了那些選擇或編寫、規劃以及安裝軟件包的人身上。

    本章描述程序員或系統管理員可以確保新編寫或購買的程序具有可接受性能的步驟。（當程序員這個詞單獨出現時，它包含系統管理員和任何對程序的最終成功負責的人。）

    為使程序達到可接受的性能，在工程開始時就要確定和量化可接受性，并且決不能忽視達到目標所需的方法和資源。盡管聽起來這是基本方法，但一些編程工程卻有意抵制它。他們采用一種清楚地描述為設計、編碼、調試、可能是編寫文檔，有時間的話再確定其性能的策略。

    為使程序運行時不僅在邏輯上，而且在時間上都是可預知的，唯一辦法就是在軟件規劃和開發過程中對性能注意事項進行整體考慮。由于安裝者較之開發者有較少的自由，所以在現有軟件安裝時提前規劃也許就更關鍵了。

    盡管對一個小程序來說，這個過程的細節可能看起來很繁重，但不要忘了我們還有第二個“記事本”。我們不僅必須保證新程序具有令人滿意的性能，還須確保該程序對現有系統的補充部分不會降低運行于該系統的其它程序的性能。

確定javascript:;" onClick="javascript:tagshow(event, '%B9%A4%D7%F7');" target="_self">工作負載的組成部分
無論程序是新編寫的還是購買的、大程序還是小程序，開發者、安裝者和預期用戶都對程序的使用有所假設，比如：

誰使用該程序
程序在何種環境下運行
這些環境出現的頻度，以及在某年某月某日某時會出現多少次
在這些環境下是否還需使用其它現有程序
程序運行于何種系統
有多少數據將要從何處進行處理
由程序或為程序創建的數據是否會在其它方面用到

    除非這些想法是作為設計過程的一部分提出的，否則很可能模糊不清，并且程序員將幾乎無疑會有與預期用戶不同的假設。甚至在程序員同時也是用戶這樣明顯很普通的情況中，讓假設無關會使以任何嚴格方式進行設計與假設的比較成為不可能。更糟的是，在對正進行的工作沒有完全理解的情況下是不可能確定性能需求的。

編寫性能需求文檔
    在確定和量化性能需求時，確定某一特殊要求背后的推理是很重要的。這是規劃過程總能力的一部分。用戶可能會將其需求聲明基于與程序員的假設不匹配的程序邏輯的假設。性能需求集至少應記錄下面幾點：

    各種特定類型的用戶 — 計算機交互作用在大部分時間會經歷的最佳響應時間，以及對大部分時間的定義。響應時間從用戶執行“運行”這個操作的時間直到用戶從計算機接收到足夠反饋以繼續執行任務來衡量。這是用戶的主觀等待時間。它不是從一個子例程的入口到第一個寫語句的時間。
如果用戶對響應時間不感興趣，而僅僅對結果感興趣，您可以詢問“當前獨立執行時間估計值的十倍”是否可以接受。如果回答“是”，您就可以繼續討論吞吐量。否則，您可以在用戶十分注意的情況下繼續討論響應時間。

最低程度可接受剩余時間的響應時間。較長的響應時間會使用戶認為系統當機。您還需要指定剩余時間，例如，一天的高峰時刻，百分之一的交互作用。在一天的某特定時間減少響應時間很難辦到，或者代價更高。 
需要的典型吞吐量和將發生的次數。這并不是臨時注意事項。例如，對一個程序的需求可能是每天運行兩次：上午 10:00 和下午 3:15。如果這是一個運行 15 分鐘，并且計劃運行于多用戶系統的有 CPU 限制的程序，則需要某種協商以便依次運行。
最大吞吐量周期的大小和計時。
綜合預期請求及其如何隨時間變化。
多用戶應用程序中每臺機器的用戶數及總用戶數。此描述應包括這些用戶登錄和注銷的次數，以及假設的擊鍵速率、完成的請求和思考次數。您可能想弄清楚思考次數是否隨前后請求而系統地變化。
用戶所做的關于工作負載要在其上運行的機器的任何假設。如果用戶頭腦中存在一臺具體的機器，那么確保您早就了解它。同樣，如果用戶所采用的是特殊類型、大小、成本、位置、互聯或任何其它變量，而這些變量將限制您滿足前述需求的能力，那么假設也變為需求的一部分。滿意程度可能不會在程序開發、測試或首次安裝的系統上進行評估。

估計工作負載的資源需求
除非您正在購買配有詳細資源需求文檔的軟件包，否則資源估計可能是性能規劃過程中最困難的任務。造成困難有如下幾個原因：

執行任何任務都有幾種方法。您可以編寫 C（或其它高級語言）程序、shell 腳本、perl 腳本、awk 腳本、sed 腳本、AIXwindows 對話等等。從性能觀點看，一些看來特別適合算法和程序員生產力的技術非常昂貴。
有一條準則很有用，即，抽象級別越高，就越要謹慎，以確保某個系統不會承受令人驚訝的性能。請仔細考慮由一些明顯無害的構造所暗示的數據量大小和迭代數量。

單個過程的精確成本是很難確定的。困難之處不僅僅是技術上的；還有哲學上的。如果多用戶運行的給定程序的多個實例正在共享程序文本頁面，則哪一個進程應該負責那些內存頁面呢？操作系統將最近用過的文件頁面保留在內存中，以便為重新訪問該數據的程序提供高速緩存的效果。重新訪問數據的程序應該對用來保留數據的空間負責嗎？某些評估的粒度，比如系統時鐘，可以在用于同一程序連續實例的 CPU 時間上產生變化。
有兩種方法來處理資源報告的模糊性和可變性。第一種是忽略模糊性，持續消除可變性的來源，直到評估變得可一致性接受。第二種方法是嘗試讓評估盡可能真實，并從統計上描述結果。注意后者產生與生產環境有某種相關性的結果。

系統很少專門運行單個程序的單個實例。存在幾乎一直處于運行的守護程序、頻繁的通信活動和通常來自多個用戶的工作負載。這些活動很少線性增加。例如，增加給定程序的實例個數幾乎沒有增加使用的新程序文本頁面數，因為大部分程序已存在于內存中。但是，附加的進程可能導致對處理器高速緩存的額外爭用，所以，不僅其它進程不得不和新進程共享處理器時間，而且所有進程都會經歷執行每條指令需要更多周期的情況。這實際上使得處理器速度減慢，結果導致更頻繁的高速緩存未命中。
為使您的估計與具體情況所允許的一樣真實，請使用以下準則：

如果程序存在，對最類似您自己需求的現有安裝進行評估。最好的方法是使用容量規劃工具，如 BEST/1。
如果沒有合適的安裝可用，則進行試安裝并對綜合工作負載進行評估。
如果生成與需求相匹配的綜合工作負載是不實際的，則評估個體的交互作用并將結果用作仿真輸入。
如果程序還不存在，查找使用同種語言和通用結構的同等程序并對其進行評估。再次強調，語言越抽象，在確定可比性時就越需謹慎。
如果同等程序不存在，則用規劃的語言開發一個主要算法的原型，對這個原型進行評估并對工作負載建模。
只有當任何類型的評估都是不可能或不可行的，您才應作一個有根據的猜測。如果在規劃階段有必要對資源需求進行猜測，則在其開發階段盡早對實際程序進行評估是很關鍵的。
牢記獨立軟件供應商（ISV）對他們的應用程序常常有可縮放的準則。

在估計資源時，我們主要對四個方面感興趣（無特殊順序）：

CPU 時間
工作負載的處理器成本
磁盤訪問
工作負載產生的磁盤讀寫速率
LAN 流量
工作負載生成的信息包數目和交換的數據字節數
實內存
工作負載所需 RAM 的大小
以下各節討論了在各種情況下如何確定這些值。

評估工作負載資源
如果實際程序、可比程序或原型對評估都是可用的，則技術方法的選擇依賴以下幾點：

除了我們要評估的工作負載以外，系統是否還在處理其它工作。
我們是否有權使用會降低性能的工具（例如，系統是否處于生產中或在評估持續時間中是否為我們所專用？）.
我們能夠模擬或觀察真實工作負載的程度。

估計新程序需要的資源
對未編寫的程序進行精確估計是不可能的。編碼階段發生的創作和重新設計是難以預見的，但下面的準則可以幫助您對需求有一個全面了解。作為一個起點，最小程序需要以下條件：

大約 50 毫秒的 CPU 時間，大部分是系統時間。
實內存
一個程序文本頁面
大約 15 個頁面（其中 2 個是暫存頁面）用于工作（數據）段
對 libc.a 進行訪問。通常這和所有其它程序共享，并當作操作系統基本成本的一部分。
大約 12 個頁面調進的磁盤 I/O 操作（如果程序最近尚未編譯、復制或使用）。否則什么都不需要。
除了上述一些方面，還有由設計所隱含要求的基本成本容差（給出的單元僅作示例用）：

CPU 時間
不包含高級迭代或昂貴子例程調用的普通程序的 CPU 消耗小得幾乎不可測量。
如果提到的程序包含計算復雜的算法，則開發一個原型，對算法進行評估。
如果提到的程序使用計算復雜的庫子例程，如 X 或 Motif 構造或 printf() 子例程，則用其它小程序對它們的 CPU 消耗進行評估。
實內存
每個程序文本頁面允許大約 350 行代碼，其中每行大約 12 字節。不要忘了編碼風格與編譯器選項可在任一方面產生一兩種因素的差異。該容差是針對與您典型情況相關的頁面的。如果您的設計在可執行程序的結束處安插有執行次數很少的子例程，則那些頁面通常不消耗實內存。
引用共享庫而不是 libc.a 會增加內存需求，僅從這個意義上來說，那些庫并不與其它程序或正在估計程序的實例共享。為量度這些庫的大小，請編寫一個長期運行的引用那些庫的小程序，并對進程使用 svmon -P 命令。
估計在設計中所確定的數據結構所需存儲量大小。集中到最靠近的頁面。
在短時間的運行中，每一個磁盤 I/O 操作使用一個內存頁面。假設頁面必須已是可用的。不要假設程序會等待另一個程序的頁面釋放。
磁盤 I/O
對于順序 I/O，每讀或寫 4096 字節導致一個 I/O 操作，除非文件最近剛被訪問過并且一些頁面仍留在內存中。
對于隨機 I/O，每一次對不同的 4096 字節頁面的訪問，無論大小，都會導致一個 I/O 操作，除非文件最近剛被訪問過并且一些頁面仍留在內存中。
每一次對大文件進行 4 KB 頁面的順序讀寫會占用大約 100 個單元。每一次進行 4 KB 頁面的隨機讀寫會占用大約 300 個單元。記住實際文件不一定順序存儲在磁盤上，盡管程序對它們進行順序寫和讀。因此，與順序存取成本相比，實際磁盤存取的典型 CPU 成本與隨機存取成本更接近。
通信 I/O
如果磁盤 I/O 實際上是對網絡文件系統（NFS）遠程安裝的文件系統的，則磁盤 I/O 在服務器上執行，但客戶機會承擔更高的 CPU 和內存要求。
任何一種 RPC 對 CPU 負載都有非常大的貢獻。設計中提出的 RPC 應該預先進行最小化、批處理、原型化和評估。
每一次進行 4 KB 頁面的順序 NFS 讀或寫會占用客戶機大約 600 個單元。每一次進行 4 KB 頁面的隨機 NFS 讀或寫會占用客戶機大約 1000 個單元。
Web 瀏覽和 Web 服務暗示有大量的網絡 I/O，同時 TCP 連接的打開和關閉非常頻繁。
變換程序級別估計為工作負載估計
估計高峰和典型資源需求的最好方法是使用排隊模型，如 BEST/1。您可以使用靜態模型，但有冒高估或低估高峰資源的危險。在任一情況下，從資源需求的觀點出發，您都需要理解工作負載中的多個程序是如何交互的。

如果您正在構建一個靜態模型，請使用時間間隔，這是對大多數頻繁運行或苛求的程序（通常兩者是相同的）而言可接受性最差的響應時間。決定在每個時間間隔中通常運行哪些程序，這要基于您所規劃的用戶數、他們的思考次數、擊鍵輸入速率以及預期的混合操作。

使用以下準則：

CPU 時間
在時間間隔中運行的所用程序的 CPU 需求總和。包括程序正要執行的磁盤和通信 I/O 的 CPU 需求。
如果在時間間隔中這個數字大于可用 CPU 時間的 75%，則應考慮減少用戶數或增加 CPU。
實內存
操作系統內存需求隨物理內存大小而變化。操作系統本身使用 6 到 8 MB。單機系統中該數字更小。后一個數字是對 LAN 連接以及使用 TCP/IP 和 NFS 的系統而言的。
在時間間隔中運行的程序所有實例的工作段需求總和，包括為程序數據結構所估計的空間。
即將運行的每個不同程序文本段的內存需求（一個程序文本副本為該程序所有實例服務）的總和。記住來自非共享庫的任何（且僅僅）子例程將成為可執行程序的一部分，但這些庫本身并不在內存中。
每一個由工作負載中任何程序使用的共享庫所消耗的空間大小總和。再次強調，一個副本可供所有實例使用。
為了提供足夠的空間用作某種文件高速緩存和自由列表，您的內存規劃總和不應超過要使用的機器大小的 80%。
磁盤 I/O
每個程序的每個實例所暗示的 I/O 總數。分別計算小文件（或隨機讀寫的大文件）與完全順序讀或寫的大文件（大于 32 KB）的 I/O 總數。
除去那些您認為可以從內存中獲得的 I/O。前一個時間間隔的任何讀或寫記錄在當前時間間隔中很可能仍然可用。此外，檢查提出的機器的大小并與機器工作負載的總 RAM 需求對比。操作系統需求與工作負載需求之外的所有剩余空間可能包含最近讀或寫的文件頁面。如果您的應用程序設計如上面所述，那么很有可能您會重新使用最近訪問過的數據，您可以針對高速緩存的效果計算容差。記住重新使用是在頁面級別上，而不是記錄級別上。如果重新使用一條給定記錄的可能性很低，但每個頁面又有大量記錄，則在任何給定時間間隔中需要的一些記錄可能會像最近使用過的其它記錄一樣落在同一頁面中。
把凈 I/O 需求（每張磁盤每秒鐘的磁盤 I/O）與當前磁盤驅動器的近似容量相比較。如果隨機或順序需求超過要保存應用程序數據的相應的磁盤總容量的 75%，那么就有必要在應用程序運行時進行調諧（并且可能是擴展）。
通信 I/O
計算工作負載的帶寬消耗。如果 LAN 上所有節點的總帶寬消耗大于額定帶寬的 70%（以太網中的 50%），您可能想使用帶寬更高的網絡。
對要加在服務器上的額外負載的 CPU、內存和 I/O 需求進行類似分析。
注:
記住只有當不可能進行綜合評估時，這些準則才有用。任何可用來代替某個準則的應用程序特定的評估都會顯著提高估計的精確性。