- 相關(guān)推薦
Java EE性能的測試與調(diào)優(yōu)
JavaEE，是由Sun Microsystems公司于1995年5月推出的Java程序設(shè)計語言和Java平臺的總稱。下面yjbys小編為大家準(zhǔn)備了關(guān)于Java EE性能的測試與調(diào)優(yōu)，歡迎閱讀。
性能測試的目標(biāo)
性能測試不同于功能測試，不是對與錯的檢驗，而是快與慢的衡量。在進行真正的性能測試之前要先搞清楚目標(biāo)：
1. 在確定的硬件條件下，可以支持的并發(fā)數(shù)越大越好，響應(yīng)時間越快越好。具體需要達到的并發(fā)數(shù)是多大，要求的響應(yīng)時間是多快，由產(chǎn)品經(jīng)理來提出。
2. 在確定的硬件條件下，測試得到最大并發(fā)數(shù)和相應(yīng)的響應(yīng)時間之后。如果增加硬件投入，可以得到怎樣的性能提升回報? (系統(tǒng)擴展性和伸縮性測試，Scalability)
這里的硬件條件包括：cpu，memery，I/O，network bandwidth。
性能測試中的基準(zhǔn)測試 Benchmarking
與功能測試相似，性能測試也要設(shè)計測試用例，不同的是在正式開始你的業(yè)務(wù)測試用例之前你要先進行一下基準(zhǔn)測試。為什么呢?其實就是先要量一下你的硬件的能力，不然，如果你的測試結(jié)果不好，你怎么知道是硬件慢還是你的軟件的問題。這些硬件測試包括：
1. 網(wǎng)絡(luò)帶寬測試， 你可以通過copy大文件的方式測試你的網(wǎng)絡(luò)的最大帶寬是多少。
2. cpu，你可以利用比較復(fù)雜的算法來衡量cpu的快慢
3. memery，這個不用測試，你知道m(xù)emery的大小
4. IO， 也可以通過copy大文件來測試
這些基準(zhǔn)測試用例在后面的調(diào)優(yōu)過程中，還可以用來衡量你修改之后真的變好了嗎。
設(shè)計你的業(yè)務(wù)測試用例
比較理想的測試用例就是要盡可能模仿真實世界的情況，這往往做不到，尤其是對于新產(chǎn)品來說。你可以先錄制一些用戶最常用，最典型的case作為起點。
另外，對于并發(fā)的概念需要搞清楚。并發(fā)用戶，通常是指同時在線的用戶，這些用戶可以能在用你的系統(tǒng)的不同的功能，注意并不是說大家都在做同一件事情。對某一個事務(wù)并發(fā)請求是指某一個request的并發(fā)調(diào)用。
對于后一種并發(fā)，你往往需要計算在用戶量最大的時候，大概大家都集中的在干哪一件事情，這個請求一定要夠快才好。
設(shè)計好這兩種測試用例以后，在后面的調(diào)優(yōu)過程中，他們就成了衡量你的改進的成效的衡量的標(biāo)尺。
性能調(diào)優(yōu)
性能調(diào)優(yōu)要從底層開始，基本上要從OS開始，到JVM，Cache，Buffer Pool， SQL，DB Schema， 算法。
一次不要改的太多，改一點，測一下，這可是個慢功夫，需要有耐心。
在執(zhí)行測試的時候還要注意，要遵循相同的過程，系統(tǒng)需要在重啟之后先熱身再開始真正的測試，不然你會發(fā)現(xiàn)你的測試結(jié)果很不一樣，琢磨不定。
還有，要注意你的客戶端的能力，比如JMeter，很需要內(nèi)存，別因為客戶端不行，誤以為是你的系統(tǒng)的問題，那就太烏龍了。
在測試調(diào)優(yōu)的時候，需要借助一些監(jiān)控工具比如JConsole，來監(jiān)控系統(tǒng)的狀況，找到系統(tǒng)的瓶頸，所謂瓶頸，就是最慢的那個部分，也常表現(xiàn)為100%被占滿。比如你的內(nèi)存或者cpu被用盡了。如果cpu和內(nèi)存還沒有用盡，說明他們在等某個資源。這時候需要用profile工具去尋找，比如JProfile，YourKit。
利用性能監(jiān)控日志
因為性能的問題不是很容易重現(xiàn)，當(dāng)product環(huán)境中遇到性能問題的時候，如果是數(shù)據(jù)的問題，也許當(dāng)你把product 數(shù)據(jù)copy到你的測試環(huán)境中，就能重現(xiàn)比較慢點查詢，加以改進。但是如果是并發(fā)用戶或者網(wǎng)絡(luò)等運行時環(huán)境的問題，你就很難重現(xiàn)。這時，如果你能通過日志看到那些關(guān)鍵的響應(yīng)慢的方法，也許可以幫助你快點找到問題所在。下面的代碼可以幫你做到這一點，僅供參考：
import org.slf4j.Logger;
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) {
this.logger = logger;
this.threadInfo = thread.getId() + "-" + thread.toString();
this.targetId = targetId;
this.begin = begin;
}
public void trace(String targetEvent) {
long duration = System.currentTimeMillis() - begin;
long increment = duration - offtime;
offtime = duration;
float percentage = (float) increment / (float) duration * 100;
if (duration > threshold && percentage > 20) {
logger.error(
"Response time is too large: [{}], {}/{} ({}), {}, {}",
new String[] { threadInfo + "", increment + "",
duration + "", percentage + "%", targetEvent,
targetId });
}
}
}
利用JVM的MXBean找到blocked的點
當(dāng)你發(fā)現(xiàn)JVM占用的cpu很高，而且響應(yīng)時間比較慢，很可能是被IO或者網(wǎng)絡(luò)等慢速設(shè)備拖住了。也有可能是你的方法中某個同步點(同步方法或者對象)成為性能的瓶頸。這時候你可以利用JVM提供的monitor API來監(jiān)控：
同步是性能的一大瓶頸
通過監(jiān)控發(fā)現(xiàn)，大量線程block在一個同步方法上，這樣cpu也使不上勁。當(dāng)你發(fā)現(xiàn)性能上不去，IO和網(wǎng)絡(luò)等慢速設(shè)備也不是問題的時候，你就得檢查一下是否在某個關(guān)鍵點上使用了同步(synchronizae)。有時候也許是你應(yīng)用的第三方的jar里面的某個方法是同步的，這種情況下，你就很難找到問題所在。只能在編寫代碼的時候看一下你引用的方法是否是同步的。
【Java EE性能的測試與調(diào)優(yōu)】相關(guān)文章：
影響Java EE性能的因素10-05
j2ee與java的區(qū)別08-10
j2ee與java web的區(qū)別09-19
高性能J2EE應(yīng)用的技巧07-21
構(gòu)建高性能J2EE應(yīng)用的技巧07-20
Java Web開發(fā)和J2EE的區(qū)別07-07
Linux系統(tǒng)Web服務(wù)器性能測試08-06
2016年J2EE認證測試題及答案09-27