性能的測量
性能只有在你決定測量性能的時候性能才是重要的。但一些人發現在測量性能的時候，很難確定需要測量哪個度量值，而且就算他們手頭上有了這些信息之后也不知道該怎么辦。結果導致了很多人開始竭盡全力地獲得所有相關信息。這當然也導致了系統負載過重和獲得一些看起來沒有意義的信息。在這樣的情況下，一些人完全放棄了測量，開始憑着他們的直覺對系統性能調優。
我們當然不能這么干，而應該系統地並且一步一步地對它進行測量。首先，理解為什么要測量性能和通過這些工作你想達到一個什么目標。如果你沒有一個目標，那么就沒有辦法去完成了。
接下來你需要理解你測量的東西和它們的意義。這可能需要創建一個模型用於跟蹤你的數據。只有通過結合數據和模型，你才能獲得有價值的信息。例如，預報天氣需要一些數據：氣溫，濕度，大氣壓力等等。即使我知道它們的每一個值，如果我沒有該地區的氣候模型我還是不能預報那個地區的天氣情況。原始度量值不易理解，在一個有意義的模型中度量值會更易於理解。
測量的變量
讓我們開始看看我們的模型需要收集那些度量值信息。我們需要理解系統一些最基本的東西是：
反應時間（R）
吞吐量（X）
資源利用率（U）
服務請求（D）
反應時間 用於測量完成一個特定請求需要花費多少時間。它是一個非常重要的度量值因為它是用戶體驗的一個指數。盡管這樣，你必須確保你理解你測量的是什么--系統級的反應時間和組件級的反應時間完全不同（因為系統級包括像隊列時間這樣的變量）。
它同時也是不容易測量的度量值，因為它比其它的度量值更容易變化。因此你必需了解反應時間的分布。如果應用對你大部分用戶的反應時間是2秒鍾，而對10％用戶的反應時間卻是10秒鍾，在這種情況下，你必須知道這個反應時間的分布，才能精確地評估該問題和解決它。這就要測量它們的反應時間並且得到它們的標准偏差，理想的情況是用一個柱狀圖把反應時間的分布顯示出來。
吞吐量 指出系統在一段時間內能執行的交易量。它是系統處理負載能力的一個很好的指數，並且通常跟反應時間結合在一起。由於它不是以用戶為中心的測量，所以對於一些非交互的系統或批處理工作，它是最值得考慮的。
資源利用率 是用於測量系統特定元素被利用了多少。這個度量值是系統的最底層情況的一個指數，因此對於容量規划是有用的。它也是非常容易理解的度量值，許多人通常都是從處理器和內存的利用率開始入手的，但它不是測量系統性能中最有用的。
我們發現更多使用的是處於請求中的資源。我們使用稱為 服務請求 （D）的計算度量值顯示特定資源或服務將怎樣被利用。服務請求用以下公式計算：
D=U/X
這給了我們一個比較清晰的資源利用率，對於吞吐量是規范化的。
相互關聯的度量值
上面這些度量值之間都有關系，理解它們的關系是創建性能模型重要的第一步。為了清楚理解它們，我們能夠以圖表的形式畫出這些關系（見下圖）
通過這個圖，我們可以更清楚看到一些東西。我們注意吞吐量（X）和反應時間（R）經常是成正比增長的。在實驗室設置中，或者對於非交互的應用，我們通常將想獲得最高的吞吐量。對於用戶驅動的生產環境，我們通常想最大化吞吐量，而保持大部分請求時間低於或等於某個反應時間。例如，當保持95％的請求反應時間等於或少於2秒的時候，我們可能想最大化我們的吞吐量。由於這些限制，我們可能發現我們能夠達到每秒100個交易的最大吞吐量。
細看這個圖，我們發現資源利用率通常控制着系統行為。這里有一個資源論點，認為資源競爭導致了吞吐量的急劇下降和提高了反應時間，吞吐量下降的量和增加的反應時間量是相同的，形成了扣環圖。扣環圖引起應用性能的服務下降，因為系統花費大部分的時間管理資源競爭而不是服務請求。創建一個系統性能模型看你的應用中這三個度量值是怎么個情況是很重要的。你也想知道：哪個度量值引起負載飆升以及這個度量值的精確值？知道了引起應用負載飆升的值對於在產品監控工具中設置報警值是非常有用的。
度量值與系統模型
確定了測量的度量值，我們現在准備開始把這些數據放到我們的模型中。
常用軟件系統一般由四個主要過程組成的：客戶請求處理，包括發起的請求和這些請求可能綁定的會話；請求執行管理，請求被指派到執行線程前排隊等候的地方；應用程序，包括所有程序的代碼；底層服務服務，包括了常用的元素，像JDBC和 JMS，也有在你的應用和外界之間的連接。當然，所有這些元素都可能運行在某平台或者虛擬機中，比如JVM，而JVM則使用操作系統資源如處理器CPU，內存，物理磁盤和網絡連接。下圖是一個J2EE模型。
我們現在能夠看到怎樣在每一層上測量前面討論過的度量值。我們需要測量和理解反應時間在各個層中的分布，這些層包括客戶請求和處理層，應用代碼層（在組件，方法或語句層細節中），還有服務。在客戶請求處理層中吞吐量是最重要的--我們必須知道我們的系統能處理多少用戶負載。在系統中資源利用率是通過很多不同點（操作系統，執行線程，服務等）來測量的，所以我們能關聯這些信息並且看到系統中不同元素是怎么互相影響的。
測量的開銷
天底下沒有免費的午餐。在任何時候，當你實時地測量這些度量值時，你總會給系統增加一些負載。通過了解由於我們測量引起的負載，我們將能夠在打算獲得的信息量和可能增加的負載之間作出明智的選擇。測量這些負載的最好方法是使用前面提到過的服務請求來計算。
在創建系統性能的准確模型時，必須理解在測量時產生負載的影響。J2EE應用是由一些相互聯系的系統組成的，並且這些系統在運行時有輕微的不同。處理它的唯一辦法是確保鎖定你能鎖定的一切東西--你不想你的性能測量由批處理任務組成，這些批處理任務會在你的服務器中的某一台突然啟動。定期的重做基准測試也是一個好辦法。這將確保你很快意識到系統性能的突然下降，性能突然下降會使你的數據無效。
測試與分析
在建立了測試模型，明確了個組件的測試重點后，便可以應用早期提到的性能測試和監控方法獲得測試數據，再對測試數據進行分析即可。
一個i/o評估的小例子
通常，我們很容易觀察到數據庫服務器的內存和CPU壓力。但是對I/O壓力沒有直觀的判斷方法。磁盤有兩個重要的參數： Seek time、 Rotational latency。正常的I/O計數為：
①1000/(Seek time+Rotational latency)*0.75
在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下，磁盤的隨機讀計數為125、順序讀計數為225。對於數據文件而言是隨機讀寫，日志文件是順序讀寫。因此，數據文件建議存放於RAID5上，而日志文件存放於RAID10或RAID1中。
下面假設在有4塊硬盤的RAID5中觀察到的Physical Disk性能對象的部分值：
Avg. Disk Queue Length 12
Avg. Disk Sec/Read .035
Avg. Disk Sec/Write .045
Disk Reads/sec 320
Disk Writes/sec 100
Avg. Disk Queue Length，12/4=3，每塊磁盤的平均隊列建議不超過2。
Avg. Disk Sec/Read一般不要超過11～15ms。
Avg. Disk Sec/Write一般建議小於12ms。
從上面的結果，我們看到磁盤本身的I/O能力是滿足我們的要求的，原因是因為有大量的請求才導致隊列等待，這很可能是因為你的SQL語句導致大量的表掃描所致。在進行優化后，如果還是不能達到要求，下面的公式可以幫助你計算使用幾塊硬盤可以滿足這樣的並發要求：
Raid 0 -- I/Os per disk = (reads + writes) / number of disks
Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks
我們得到的結果是：(320+400)/4=180，這時你可以根據公式①來得到磁盤的正常I/O值。假設現在正常I/O計數為125，為了達到這個結果：720/125=5.76。就是說要用6塊磁盤才能達到這樣的要求。
但是上面的Disk Reads/sec和Disk Writes/sec是個很難正確估算的值。因此只能在系統比較忙時，大概估算一個平均值，作為計算公式的依據。另一個是你很難從客戶那里得到Seek time、 Rotational latency參數的值，這也只能用理論值125進行計算。