Java EE效能的測試與調優

JavaEE，是由Sun Microsystems公司於1995年5月推出的Java程式設計語言和Java平臺的總稱。下面yjbys小編為大家準備了關於Java EE效能的測試與調優，歡迎閱讀。

　　效能測試的目標

效能測試不同於功能測試，不是對與錯的檢驗，而是快與慢的衡量。在進行真正的效能測試之前要先搞清楚目標：

1. 在確定的硬體條件下，可以支援的併發數越大越好，響應時間越快越好。具體需要達到的併發數是多大，要求的響應時間是多快，由產品經理來提出。

2. 在確定的硬體條件下，測試得到最大併發數和相應的響應時間之後。如果增加硬體投入，可以得到怎樣的效能提升回報? (系統擴充套件性和伸縮性測試，Scalability)

這裡的硬體條件包括：cpu，memery，I/O，network bandwidth。

效能測試中的基準測試 Benchmarking

與功能測試相似，效能測試也要設計測試用例，不同的是在正式開始你的業務測試用例之前你要先進行一下基準測試。為什麼呢?其實就是先要量一下你的硬體的能力，不然，如果你的測試結果不好，你怎麼知道是硬體慢還是你的軟體的問題。這些硬體測試包括：

1. 網路頻寬測試， 你可以通過copy大檔案的方式測試你的網路的最大頻寬是多少。

2. cpu，你可以利用比較複雜的演算法來衡量cpu的快慢

3. memery，這個不用測試，你知道memery的大小

4. IO， 也可以通過copy大檔案來測試

這些基準測試用例在後面的調優過程中，還可以用來衡量你修改之後真的變好了嗎。

　　設計你的業務測試用例

比較理想的測試用例就是要儘可能模模擬實世界的情況，這往往做不到，尤其是對於新產品來說。你可以先錄製一些使用者最常用，最典型的case作為起點。

另外，對於併發的概念需要搞清楚。併發使用者，通常是指同時線上的使用者，這些使用者可以能在用你的系統的不同的功能，注意並不是說大家都在做同一件事情。對某一個事務併發請求是指某一個request的併發呼叫。

對於後一種併發，你往往需要計算在使用者量最大的時候，大概大家都集中的在幹哪一件事情，這個請求一定要夠快才好。

設計好這兩種測試用例以後，在後面的調優過程中，他們就成了衡量你的改進的成效的衡量的標尺。

　　效能調優

效能調優要從底層開始，基本上要從OS開始，到JVM，Cache，Buffer Pool， SQL，DB Schema， 演算法。

一次不要改的太多，改一點，測一下，這可是個慢功夫，需要有耐心。

在執行測試的時候還要注意，要遵循相同的過程，系統需要在重啟之後先熱身再開始真正的測試，不然你會發現你的測試結果很不一樣，琢磨不定。

還有，要注意你的客戶端的.能力，比如JMeter，很需要記憶體，別因為客戶端不行，誤以為是你的系統的問題，那就太烏龍了。

在測試調優的時候，需要藉助一些監控工具比如JConsole，來監控系統的狀況，找到系統的瓶頸，所謂瓶頸，就是最慢的那個部分，也常表現為100%被佔滿。比如你的記憶體或者cpu被用盡了。如果cpu和記憶體還沒有用盡，說明他們在等某個資源。這時候需要用profile工具去尋找，比如JProfile，YourKit。

　　利用效能監控日誌

因為效能的問題不是很容易重現，當product環境中遇到效能問題的時候，如果是資料的問題，也許當你把product 資料copy到你的測試環境中，就能重現比較慢點查詢，加以改進。但是如果是併發使用者或者網路等執行時環境的問題，你就很難重現。這時，如果你能通過日誌看到那些關鍵的響應慢的方法，也許可以幫助你快點找到問題所在。下面的程式碼可以幫你做到這一點，僅供參考：

import er;

public class TraceUtil {

final Logger logger;

final long threshold = 1000;

private long begin;

private long offtime = 0;

private String threadInfo;

private String targetId;

public TraceUtil(Logger logger, Thread thread, String targetId, long begin) {

er = logger;

adInfo = d() + "-" + ring();

etId = targetId;

n = begin;

}

public void trace(String targetEvent) {

long duration = entTimeMillis() - begin;

long increment = duration - offtime;

offtime = duration;

float percentage = (float) increment / (float) duration * 100;

if (duration > threshold && percentage > 20) {

r(

"Response time is too large: [{}], {}/{} ({}), {}, {}",

new String[] { threadInfo + "", increment + "",

duration + "", percentage + "%", targetEvent,

targetId });

}

}

}

　　利用JVM的MXBean找到blocked的點

當你發現JVM佔用的cpu很高，而且響應時間比較慢，很可能是被IO或者網路等慢速裝置拖住了。也有可能是你的方法中某個同步點(同步方法或者物件)成為效能的瓶頸。這時候你可以利用JVM提供的monitor API來監控：

　　同步是效能的一大瓶頸

通過監控發現，大量執行緒block在一個同步方法上，這樣cpu也使不上勁。當你發現效能上不去，IO和網路等慢速裝置也不是問題的時候，你就得檢查一下是否在某個關鍵點上使用了同步(synchronizae)。有時候也許是你應用的第三方的jar裡面的某個方法是同步的，這種情況下，你就很難找到問題所在。只能在編寫程式碼的時候看一下你引用的方法是否是同步的。