如何進(jìn)行Java EE性能測試與調優(yōu)

　　性能測試的目標

　　性能測試不同于功能測試，不是對與錯的檢驗，而是快與慢的衡量。在進(jìn)行真正的性能測試之前要先搞清楚目標：

　　1. 在確定的硬件條件下，可以支持的并發(fā)數越大越好，響應時(shí)間越快越好。具體需要達到的并發(fā)數是多大，要求的響應時(shí)間是多快，由產(chǎn)品經(jīng)理來(lái)提出。

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

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

　　性能測試中的基準測試 Benchmarking

　　與功能測試相似，性能測試也要設計測試用例，不同的是在正式開(kāi)始你的業(yè)務(wù)測試用例之前你要先進(jìn)行一下基準測試。為什么呢?其實(shí)就是先要量一下你的硬件的能力，不然，如果你的測試結果不好，你怎么知道是硬件慢還是你的軟件的問(wèn)題。這些硬件測試包括：

　　1. 網(wǎng)絡(luò )帶寬測試， 你可以通過(guò)copy大文件的方式測試你的網(wǎng)絡(luò )的最大帶寬是多少。

　　2. cpu，你可以利用比較復雜的算法來(lái)衡量cpu的快慢

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

　　4. IO， 也可以通過(guò)copy大文件來(lái)測試

　　這些基準測試用例在后面的調優(yōu)過(guò)程中，還可以用來(lái)衡量你修改之后真的變好了嗎。

　　設計你的業(yè)務(wù)測試用例

　　比較理想的測試用例就是要盡可能模仿真實(shí)世界的情況，這往往做不到，尤其是對于新產(chǎn)品來(lái)說(shuō)。你可以先錄制一些用戶(hù)最常用，最典型的case作為起點(diǎn)。

　　另外，對于并發(fā)的概念需要搞清楚。并發(fā)用戶(hù)，通常是指同時(shí)在線(xiàn)的用戶(hù)，這些用戶(hù)可以能在用你的系統的不同的功能，注意并不是說(shuō)大家都在做同一件事情。對某一個(gè)事務(wù)并發(fā)請求是指某一個(gè)request的并發(fā)調用。

　　對于后一種并發(fā)，你往往需要計算在用戶(hù)量最大的時(shí)候，大概大家都集中的在干哪一件事情，這個(gè)請求一定要夠快才好。

　　設計好這兩種測試用例以后，在后面的調優(yōu)過(guò)程中，他們就成了衡量你的改進(jìn)的成效的衡量的標尺。

　　性能調優(yōu)

　　性能調優(yōu)要從底層開(kāi)始，基本上要從OS開(kāi)始，到JVM，Cache，Buffer Pool， SQL，DB Schema， 算法。

　　一次不要改的太多，改一點(diǎn)，測一下，這可是個(gè)慢功夫，需要有耐心。

　　在執行測試的時(shí)候還要注意，要遵循相同的過(guò)程，系統需要在重啟之后先熱身再開(kāi)始真正的測試，不然你會(huì )發(fā)現你的測試結果很不一樣，琢磨不定。

　　還有，要注意你的客戶(hù)端的能力，比如JMeter，很需要內存，別因為客戶(hù)端不行，誤以為是你的系統的問(wèn)題，那就太烏龍了。

　　在測試調優(yōu)的時(shí)候，需要借助一些監控工具比如JConsole，來(lái)監控系統的狀況，找到系統的瓶頸，所謂瓶頸，就是最慢的那個(gè)部分，也常表現為100%被占滿(mǎn)。比如你的內存或者cpu被用盡了。如果cpu和內存還沒(méi)有用盡，說(shuō)明他們在等某個(gè)資源。這時(shí)候需要用profile工具去尋找，比如JProfile，YourKit。

　　利用性能監控日志

　　因為性能的問(wèn)題不是很容易重現，當product環(huán)境中遇到性能問(wèn)題的時(shí)候，如果是數據的問(wèn)題，也許當你把product 數據copy到你的測試環(huán)境中，就能重現比較慢點(diǎn)查詢(xún)，加以改進(jìn)。但是如果是并發(fā)用戶(hù)或者網(wǎng)絡(luò )等運行時(shí)環(huán)境的問(wèn)題，你就很難重現。這時(shí)，如果你能通過(guò)日志看到那些關(guān)鍵的響應慢的方法，也許可以幫助你快點(diǎn)找到問(wèn)題所在。下面的代碼可以幫你做到這一點(diǎn)，僅供參考：

　　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的點(diǎn)

　　當你發(fā)現JVM占用的cpu很高，而且響應時(shí)間比較慢，很可能是被IO或者網(wǎng)絡(luò )等慢速設備拖住了。也有可能是你的方法中某個(gè)同步點(diǎn)(同步方法或者對象)成為性能的瓶頸。這時(shí)候你可以利用JVM提供的monitor API來(lái)監控：

　　同步是性能的一大瓶頸

　　通過(guò)監控發(fā)現，大量線(xiàn)程block在一個(gè)同步方法上，這樣cpu也使不上勁。當你發(fā)現性能上不去，IO和網(wǎng)絡(luò )等慢速設備也不是問(wèn)題的時(shí)候，你就得檢查一下是否在某個(gè)關(guān)鍵點(diǎn)上使用了同步(synchronizae)。有時(shí)候也許是你應用的第三方的jar里面的某個(gè)方法是同步的，這種情況下，你就很難找到問(wèn)題所在。只能在編寫(xiě)代碼的時(shí)候看一下你引用的方法是否是同步的。

原文轉自：http://kjueaiud.com