內(nèi)容: 解決JAVA服務(wù)器性能問題通過負(fù)載測試和分析來改善JAVA服務(wù)器應(yīng)用的性能作者：Ivan Small譯者:xMatrix版權(quán)聲明：任何獲得Matrix授權(quán)的網(wǎng)站，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明作者:Ivan Small;xMatrix原文地址:http://www.javaworld.com/javaworld/jw-02-2005/jw-0207-server-p3.html中文地址:http://www.matrix.org.cn/resource/article/43/43998_server_capacity.html關(guān)鍵詞： server capacity摘要改善JAVA服務(wù)器的性能需要模擬負(fù)載下的服務(wù)器。創(chuàng)建一個模擬環(huán)境、搜集數(shù)據(jù)并且分析結(jié)果可能是對許多開發(fā)人員的挑戰(zhàn)。這篇文章中的示例介紹了JAVA服務(wù)器性能分析的概念和工具。作者使用這個示例來研究超額請求次數(shù)下內(nèi)存使用和同步竟?fàn)幍挠绊憽Ｗ髡逫van Small項目團(tuán)隊已經(jīng)很熟悉如何組織一些具體的任務(wù)并完成他們。簡單的性能問題很容易由一個開發(fā)人員分離并解決。然而大的性能問題，通常在系統(tǒng)處于高負(fù)載情況下發(fā)生，就不是這么簡單能處理的了。這些問題需要一個獨立的測試環(huán)境、一個模擬的負(fù)載，并且需要仔細(xì)地分析和跟蹤。在這篇文章中，我使用比較通用的工具和設(shè)備創(chuàng)建了一個測試環(huán)境。我會專注于兩個性能問題，內(nèi)存和同步，他們很難用簡單的分析得到。通過一個具體的例子，我希望比較容易地解決復(fù)雜的性能問題而且可以提供處理問題過程中的細(xì)節(jié)。改善服務(wù)器的性能服務(wù)器的性能改善是依賴于數(shù)據(jù)的。沒有可靠的數(shù)據(jù)基礎(chǔ)而更改應(yīng)用或環(huán)境會導(dǎo)致更差的結(jié)果。分析器提供有用的JAVA服務(wù)器應(yīng)用信息，但由于從單用戶負(fù)載下的數(shù)據(jù)與多用戶負(fù)載下得到的數(shù)據(jù)是完全不同的，這導(dǎo)致分析器的數(shù)據(jù)并不精確。在開發(fā)階段使用分析器來優(yōu)化應(yīng)用的性能是一個好的方式，但在高負(fù)載下的應(yīng)用分析可以取到更好的效果。在負(fù)載下分析服務(wù)器應(yīng)用的性能需要一些基本的元素： 1、可控的進(jìn)行應(yīng)用負(fù)載測試的環(huán)境。 2、可控的人造負(fù)載使得應(yīng)用滿負(fù)荷運行。 3、來自監(jiān)視器、應(yīng)用和負(fù)載測試工具自身的數(shù)據(jù)搜集。 4、性能改變的跟蹤。不要低估最后一個需求（性能跟蹤）的重要性因為如果不能跟蹤性能你就不能實際的管理項目。性能上10-20%的改善對單用戶環(huán)境來說并沒有什么不同，但對支持人員來說就不一樣了。20%的改善是非常大的，而且通過跟蹤性能的改善，你可以提供重要的反饋和持續(xù)跟蹤。雖然性能跟蹤很重要，但有時為了使后續(xù)的測試更加精確而不得不拋棄先前的測試結(jié)果。在性能測試中，改善負(fù)載測試的精確性可能需要修改模擬環(huán)境，而這些變化是必須的，通過變化前后的負(fù)載測試你可以觀察到其中的轉(zhuǎn)變。可控的環(huán)境 可控的環(huán)境最少也需要兩臺獨立的機(jī)器和第三臺控制的機(jī)器。其中一臺用來生成負(fù)載，另一臺作為控制機(jī)與前一臺建立測試應(yīng)用并接受反饋，第三臺機(jī)器運行應(yīng)用。此外，負(fù)載和應(yīng)用機(jī)器間的網(wǎng)絡(luò)應(yīng)該與局域網(wǎng)分開。控制機(jī)接受運行應(yīng)用機(jī)器的反饋如操作系統(tǒng)、硬件使用率、應(yīng)用（特別是VM）的狀態(tài)。負(fù)載模擬最精確的模擬通常用實際的用戶數(shù)據(jù)和WEB服務(wù)器端的訪問日志。如果你還沒有實際布署或者缺少實際的用戶數(shù)據(jù)，你可以通過構(gòu)造類似的場景或詢問銷售和產(chǎn)品管理團(tuán)隊或做一些有依據(jù)的猜想。協(xié)調(diào)負(fù)載測試和實際用戶體驗是一個持續(xù)的過程。在模擬中一些用戶場景是必須的。如在一個通用地址薄應(yīng)用中，你應(yīng)該區(qū)分更新和查詢操作。在我的測試應(yīng)用中GrinderServlet類只有一個場景。單用戶連接10次訪問這個servlet（在每一次訪問間有一段暫停）。雖然這個應(yīng)用很小，我認(rèn)為這可以重復(fù)一些常見的東西。用戶通常不會連接給服務(wù)器請求而沒有間斷。如果沒有間斷，我們可能不能得到更精確的實際用戶上限。串行10個請求的另一個原因是實際應(yīng)用中不會只有一個HTTP請求。單一而又分離的請求可以影響環(huán)境中的許多因素。對Tomcat來說，會為每一個請求創(chuàng)建一個會話，并且HTTP協(xié)議允許不同的請求重用連接。我會修改一下負(fù)載測試來避免混洧。GrinderServlet類不會執(zhí)行任何排序操作，但這個需求在大部分應(yīng)用中都很普通。在這些應(yīng)用中，你需要創(chuàng)建模擬的數(shù)據(jù)集并且用他們來構(gòu)造相關(guān)用例的負(fù)載測試。例如，如果用例涉及到用戶登錄一個WEB應(yīng)用，從可能的用戶列表中選取隨機(jī)的用戶會只使用一個用戶更精確。否則，你可能不經(jīng)意地使用了系統(tǒng)緩存或其他的優(yōu)化或一些微妙的東西，而這會使得結(jié)果不正確。負(fù)載測試軟件負(fù)載測試軟件可以構(gòu)造測試場景并且對服務(wù)進(jìn)行負(fù)載測試。我會在下面的示例中使用OpenSTA測試軟件。這軟件簡單易學(xué)，結(jié)果也很容易導(dǎo)出，并且支持參數(shù)化腳本，還可以監(jiān)視信息的變化，他的主要缺點是基于Windows，但在這兒不是個問題。當(dāng)然還有很多可選項如Apache的JMeter和Mercury的LoadRunner。The GrinderServlet列表1中顯示了GrinderServlet類，列表2中顯示了Grinder類Listing 1package pub.capart;import java.io.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;public class GrindServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { Grinderv1 grinder = Grinderv1.getGrinder(); long t1 = System.currentTimeMillis(); grinder.grindCPU(13); long t2 = System.currentTimeMillis(); PrintWriter pw = res.getWriter(); pw.print('n< body> n'); pw.print('Grind Time = '+(t2-t1)); pw.print('< body> n< /html> n'); }} Listing 2package pub.capart;/*** This is a simple class designed to simulate an application consuming* CPU, memory, and contending for a synchronization lock.*/public class Grinderv1 { private static Grinderv1 singleton = new Grinderv1(); private static final String randstr = 'this is just a random string that I'm going to add up many many times'; public static Grinderv1 getGrinder() { return singleton; } public synchronized void grindCPU(int level) { StringBuffer sb = new StringBuffer(); String s = randstr; for (int i=0;i