執行任何任務都有幾種方法。您可以編寫 C(或其它高級語言)程序、shell 腳本、perl 腳本、awk 腳本、sed 腳本、AIXwindows 對話等等。從性能觀點看，一些看來特別適合算法和程序員生產力的技術非常昂貴。
有一條準則很有用，即，抽象級別越高，就越要謹慎，以確保某個系統不會承受令人驚訝的性能。請仔細考慮由一些明顯無害的構造所暗示的數據量大小和迭代數量。
單個過程的精確成本是很難確定的。困難之處不僅僅是技術上的;還有哲學上的。如果多用戶運行的給定程序的多個實例正在共享程序文本頁面，則哪一個進程應該負責那些內存頁面呢?操作系統將最近用過的文件頁面保留在內存中，以便為重新訪問該數據的程序提供高速緩存的效果。重新訪問數據的程序應該對用來保留數據的空間負責嗎?某些評估的粒度，比如系統時鐘，可以在用于同一程序連續實例的 CPU 時間上產生變化。
有兩種方法來處理資源報告的模糊性和可變性。第一種是忽略模糊性，持續消除可變性的來源，直到評估變得可一致性接受。第二種方法是嘗試讓評估盡可能真實，并從統計上描述結果。注意后者產生與生產環境有某種相關性的結果。
系統很少專門運行單個程序的單個實例。存在幾乎一直處于運行的守護程序、頻繁的通信活動和通常來自多個用戶的工作負載。這些活動很少線性增加。例如，增加給定程序的實例個數幾乎沒有增加使用的新程序文本頁面數，因為大部分程序已存在于內存中。但是，附加的進程可能導致對處理器高速緩存的額外爭用，所以，不僅其它進程不得不和新進程共享處理器時間，而且所有進程都會經歷執行每條指令需要更多周期的情況。這實際上使得處理器速度減慢，結果導致更頻繁的高速緩存未命中。
為使您的估計與具體情況所允許的一樣真實，請使用以下準則：
如果程序存在，對最類似您自己需求的現有安裝進行評估。最好的方法是使用容量規劃工具，如 BEST/1.如果沒有合適的安裝可用，則進行試安裝并對綜合工作負載進行評估。
如果生成與需求相匹配的綜合工作負載是不實際的，則評估個體的交互作用并將結果用作仿真輸入。
如果程序還不存在，查找使用同種語言和通用結構的同等程序并對其進行評估。再次強調，語言越抽象，在確定可比性時就越需謹慎。
如果同等程序不存在，則用規劃的語言開發一個主要算法的原型，對這個原型進行評估并對工作負載建模。
只有當任何類型的評估都是不可能或不可行的，您才應作一個有根據的猜測。如果在規劃階段有必要對資源需求進行猜測，則在其開發階段盡早對實際程序進行評估是很關鍵的。
牢記獨立軟件供應商(ISV)對他們的應用程序常常有可縮放的準則。
在估計資源時，我們主要對四個方面感興趣(無特殊順序)：
CPU 時間工作負載的處理器成本磁盤訪問工作負載產生的磁盤讀寫速率LAN 流量工作負載生成的信息包數目和交換的數據字節數實內存工作負載所需 RAM 的大小以下各節討論了在各種情況下如何確定這些值。
評估工作負載資源如果實際程序、可比程序或原型對評估都是可用的，則技術方法的選擇依賴以下幾點：
除了我們要評估的工作負載以外，系統是否還在處理其它工作。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
