2007年6月16日 星期六

(2005.9月號-140期)_全方位壓力測試工具JMeter

在專案設計與開發階段,通常都會必須考量到效能的要求。例如系統反應時間必須在多少時間內、至少必須支援多少使用者同時上線等。也許在現實面上無法盡如人願,但即然有這方面的要求就不要等到專案後期才想到系統效能問題。




序言

壓力測試,主要作用就在於系統軟體正式上線或系統負載到達臨界點之前,透過進行可重覆的負載測試,先行分析出系統可承受的使用者極限值與效能瓶頸,用以提供開發人員最佳化自己的程式。經過測試不僅讓開發人員對系統實際使用中的效能狀況充滿信心,同時有了對系統負載的準確數據,亦可以減少系統當機時間與其帶來的企業損失。


壓力測試是Web應用程式開發中一項重要的決策,建構一個服務大量使用者的應用系統,擁有能表示出系統能夠承受多少的負載的數據非常重要。就算單純建置一個小型網站,經過測試能夠凸顯出最終會導致伺服器崩潰的程式碼錯誤與執行緒問題。


透過模擬大量使用者請求,執行給系統施加較大的負荷,同時評估當應用程式達到了規定極限的情況下長時間的高負載中,執行處理能力與處理交易能力,進而了解系統的穩定性。無論如何,花時間對系統進行壓力測試,將可以獲得重要的效能資訊,為未來進行系統最佳化、硬體配置以及系統升級帶來便利。

JMeter簡介

Apache JMeter 是一個100%的純Java視窗應用程式,用於壓力測試和性能測量的工具。它最初被設計用於Web應用程式的測試,但後來擴展到其他測試領域。


目前JMeter可以執行HttpFTPRDBMS(關聯式資料庫)LDAPSOAPWebService等的負載以及效能測試,並且JMeter在原始設計上採開放式架構,因此也充許開發人員撰寫可執行的可插入式套件(Plug-Ins)與效能測量用的取樣器(Samplers)


Apache JMeter 可以用於對靜態的和動態的資源,如文件,ServletPerl腳本,Java 物件,資料庫和查詢,FTP伺服器等等的性能進行測試。它可以用於對伺服器,網路或物件進行繁重的負載來測試它們的強度或分析不同壓力負荷下的整體性能。你可以使用它做效能的圖形分析或在大量同時發生的負載下測試你的伺服器與其相關應用程式的穩定性。


Apache JMeter 的特性包括:

  • 能夠對HTTPFTP伺服器進行壓力和性能測試,透過JDBC也可以對任何資料庫進行同樣的測試。

  • 完全的可攜性和100% 純Java撰寫的應用程式。

  • 使用Swing和輕量級元件支援。

  • 使用多執行緒框架允許通過多個執行同時發出請求進行取樣和通過單獨的執行緒群組對不同的功能同時取樣。

  • 精心設計的圖型介面允許快速操作和更精確的計時。

  • 對於測試結果可進行快取和離線分析、重覆進行測試。

  • 高度可擴充性:

    • 可插入的取樣器允許無限制的測試能力。

    • 各種負載統計表和可插入的計時器可供選擇。

    • 資料分析和視覺化Plug-In套件提供了很好的可擴充性以及客製化。

    • 具有提供動態輸入到測試的功能,包括JavaScript

    • 支援使用Script語法的取樣器(在1.9.2及以上版本支援BeanShell)。


JMeter下載與安裝

JMeter是使用Java開發的應用程式,因此在使用前請先確定作業系統中已有J2SE Runtime Environment,接著請至http://jakarta.apache.org/jmeter 下載JMeter,目前最新版本為2.0.3,下載完成後無需安裝,解壓縮後即可使用。執行[%JMETER_HOME%/bin/jmeter.bat]啟動如圖1JMeter圖型化操作介面。


1 JMeter GUI操作介面


測試計劃(Test Plan)

在使用JMeter的觀念上,必須先建置一個Test Plan,在Test Plan中可以包含一到多個ThreadGroups,也就是使用一個執行緒來模擬一個操作者,而ThreadGroup代表模擬一組使用者。但必須注意的是,當加入愈多的執行緒,相對的系統資源消耗也愈多。

當在TestPlan中加入了所有的測試元素後,JMeter會進行Test Plan的編譯並產生JMeterEngine,之後便可以開始進行測試,JMeterEngine將建立執行緒,而每一個執行緒會在Test Plan中重覆執行。

參考圖1畫面左側的樹狀結構中,有二個根節點,Test PlanWork Bench,在Test Plan節點中的元素,代表目前欲執行的測試計劃,而尚未打算執行或正在構築的測試計劃則置於Work Bench中,當欲進行測試時再將其搬移至Test Plan中,因此我們可以在Test Plan中執行測試,在Work Bench中建構測試。

現在我們可以來正式建立一個Test Plan了,在筆者於八月份的文章中使用了JPetStore這個範例為各位示範了如何使用Maven建置這個專案,在本期的內容中,將再次使用JPetStore為基礎,建置Web Test Plan

建立並執行測試計劃

首先在Work Bench節點上按右鍵,加入Thread Group,並設定名稱為JPetStore,在執行緒群組中必須進行執行緒特性設定,參考圖2的設定Number of Threads指定了在測試案例中將啟動60個執行緒模擬使用者,並且將在將在Ramp-Up Period(in seconds)所指定的120秒內啟動完所有的執行緒。從120/60=2得知每2秒將開啟一個執行緒,另外Loop Count若勾選Forever,則這些模擬使用者會一直進行反覆的操作,也就是說,若在這個測試中,我們模擬使者登入之後登出的話,在此將會進行無限迴圈來重覆的登入與登出。而當勾選Scheduler之後,還可進行時間排程、Duration(seconds)持續測試秒數與Startup delay(seconds)延遲多少秒才開始啟動測試案例。

2 02_Thread Group


接下來於JPetStore點選[右鍵] [Add] [Config Element] [HTTP Request Defaults],指定預設的Web Server IPPortPath,同步驟加入[HTTP Cookie Manager]。在此設置HTTP Request Defaults的用意在於之後加入HTTP Request的取樣器時無需再指定起始網址路徑,而HTTP Cookie Manager用於在該測試計劃中支援Session,如圖3

3 HTTP Request DefaultsCookie Manager


現在我們可以正式加入取樣器了,參考筆者於八月份使用Maven的文章,啟動HSQLDBTomcat,並在JPetStore點選[右鍵] [Add] [Sampler] [HTTP Request],加入HTTP Request後設定Path指向[jpetstore_maven/shop/index.do]也就是JPetStore的首頁。並且再加入[Timer] [Constant Timer]模擬使用者間隔固定時間點取網頁,最後再加上取樣採集器[Listener] [Graph Results][Listener] [View Results Tree]就完成了一個簡易的Test Plan,將建構好的JPetStore Thread Group節點移至Test Plan根節點上如圖4

4 簡易的TestPlan


執行[Run] [Start]啟動JMeter進行壓力測試,在進行測試當中可隨時查看Graph ResultsView Results Tree執行狀況。亦可在取樣採集器中設定將所有取樣資料輸出至檔案,供外部程式,如Excel進行效能分析。在範例中我們從Graph Results看到了效能曲線並從View Results Tree中得知是否正確取得網頁資訊。


5 Graph Results效能曲線


使用側錄建置測試計劃

在上一節中,我們建構一個簡易的Test Plan,若只是要測試某特定網頁的效能,這樣的作法已經足夠了。但若欲以一個操作情節(Scenario)進行測試,如使用者輸入帳號密碼登入JPetStore網頁,瀏覽並選擇產品加入購物車,最後進行商品的購買並登出。則上述的測試計劃的建置就稍嫌不足了,況且手工加入多個HTTP Request進行網頁的導覽更是耗時費力。


這時對於有固定操作情節的測試計劃,可以使用JMeter建立HTTP Proxy Server對網頁操作進行側錄。而在這之前考量到在JPetStore的測試路徑,目前都指向http://localhost:8080/jpetstore_maven/ 起始的網址,在前述的操作中我們定義了預設的Server IPPort Number,但jpetstore_maven這個Context Path並未有預設值,因此必須將Context Path設定為變數,以免日後當jpetstore_maven改了之後導致Test Plan無法使用。


如圖6Test Plan的節點下加入變數名稱為CONTEXT_PATH,變數值為jpetstore_maven的使用者自定變數,並在先前設定的HTTP Request取樣器中Pathjpetstore_mavenEL語法${CONTEXT_PATH}進行替代,如先前首頁指定路徑[jpetstore_maven/shop/index.do]修改為[${CONTEXT_PATH}/shop/index.do],完成後再次進行測試,看看設定是否正確。

6 使用者自行定義變數


接下來開始進行HTTP Proxy Server的設定,在WorkBench節點執行[右鍵] [Add] [Non-Test Elements] [HTTP Proxy Server],參考圖7設定Proxy ServerPort Number8090(Tomcat已用掉8080port),指定側錄資料放置路徑(Target Controller)[Test Plan>JPetStore]節點上,並將資料元素編組方式設為[Store 1st sampler of each group only]以免側錄到太多不必要的資料。當按下[Start]時即啟動代理伺服器進行側錄,最後開啟設定瀏覽器使用的Proxy伺服器為localhost:8090並進行網頁的側錄即可。


7 HTTP Proxy Server進行側錄


結語

經過本文的說明讀者將能夠很方便的使用JMeter進行負荷與效能測試,通過使用JMeter提供的功能,我們可以使用圖型化介面建構測試計劃,同時,除了Graph ResultsView Results Tree之外讀者亦可使用其他的Listener來圖形化的測試資料,使我們能夠簡單的進行測試工作和分析測試結果。


Read More......

2007年6月15日 星期五

Pluto、JetSpeed2、Liferay佈署WicketPortlet相容性比較

需求環境

Portal(Pluto 1.1.3)http://portals.apache.org/pluto/index.html

Portal(JetSpeed2 2.1)http://portals.apache.org/jetspeed-2/

Portal(Liferay 4.2.2)http://www.liferay.com/web/guest/home

Portlet Example(Wicket 1.2.6 Portlet Example-使用SVN取得原始碼)http://svn.apache.org/repos/asf/incubator/wicket/releases/wicket-1.2.6/wicket-portlet-examples

Maven2.0.6http://maven.apache.org/

JDKSun J2SE 1.5





佈署Wicket Portlet Example結果比較

Pluto

1.首頁

2.輸入文字按下[set message]

3.點選[click here]

4.點選[Link to the second page]

5.點選[click]進行計數

6.點選[Back to page1]



JetSpeed2

1.首頁

2.輸入文字按下[set message]

3.點選[click here]

4.點選[Link to the second page]

5.點選[click]進行計數

發生了異常狀況,網址列導至:
http://localhost:8080/wicket-portlet-examples/…

6.點選[Back to page1]

無法進行下一步操作,但可以用到退鍵
回到前面正常頁後繼續執行。



Liferay

1.首頁

2.輸入文字按下[set message]

3.點選[click here]

4.點選[Link to the second page]

5.點選[click]進行計數

6.點選[Back to page1]

經過比較後,讀者們,有沒有什麼結論呢?

Read More......

2007年6月14日 星期四

取得目前有效的POM或Profiles、Settings設定

顯示目前生效的porfiles設定
mvn help:active-profiles -Doutput=/path/to/file

輸出完整的POM內容
mvn help:effective-pom -Doutput=/path/to/file

輸出完整的Setting內容
mvn help:effective-settings -Doutput=/path/to/file

Read More......

2007年6月13日 星期三

Jetspeed2 Tutorial

目前在JetSpeed2的官方網站上
已經有了一篇使用Maven2進行客製化Portal建置的教程:
連結:http://portals.apache.org/tutorials/jetspeed-2/index.html

本例中使用的版本為2.1
這篇教程目前還有一些問題:

  • 使用archtype建立Portal專案
    mvn
    archetype:create
    -DarchetypeGroupId=org.apache.portals.jetspeed-2
    -DarchetypeArtifactId=portal-archetype
    -DarchetypeVersion=2.1
    -DgroupId=org.apache.portals.tutorials
    -DartifactId=jetexpress
    -Dversion=1.0
    -DremoteRepositories=http://www.bluesunrise.com/maven2
    目前這個archtype並未真的釋出,因此若要正常下載archtypd的話,
    必須加上remoteRepositories的設定。
  • 在建立的專案上如此例jetexpress並無法執行mvn相關指令。
    其原因在於<module>etc/dbpsml</module>模組設定不正確。
    所以導致無法順利下載相關套件。
    解決方式,在根資料夾下的pom.xml中的modules設定先註解。
    然後再執行指令,如本例的mvn idea:idea -s settings.xml
    OK後再把註解的其中一個module的註解移除
    再執行mvn idea:idea依次將所有module的註解移除。
    相對的所需的套件會順利下載。
  • 在建立資料庫的etc/build.xml的第304行
    <antcall target="populate-seed-data" inheritall="on" inheritrefs="on"/>
    無法順利執行下去。當註解完成時才能順利Build成功。
  • 當建置完成後對應的Tomcat可啟動但jetexpress這個context無法執行。

事實上這個教程雖然滿正式的。但實際上來說釋出的版本並非穩定的版本。
但這篇文章並非完全不重要,建議讀者從標題為
02. Customizing Your Portal Design
03. Portlet Application Configuration
04. Portlet Development
的教程開始看,將會了解如何在一個發行版的Portal進行客製化設定的動作。

Read More......

2007年6月12日 星期二

使用Pluto與Maven2進行Portlet開發

昨天實作並整理出了一使用Maven2進行Portlets開發的文章,目前用於開發使用的是PlutoPortal實作。

會基於這樣的實作其原因是,在目前業界所開發的系統來說除了部分產品外,其他不外乎是一些專案的開發,而在專案的開發中多數實作的都是客製化的系統,當然就會有客製化的權限控管、客製化的LayerOut…客製化的…反覆都開發這些東西,老實說…很煩。

而當企業有了許許多多的系統之後,將會發現,每一個系統都要進行一次的登入,每一個系統都是管理個自的權限,進入不同的系統都要再開啟一次瀏覽器,腦袋中要記錄不同的系統的連結網址…老實說也很煩。



為了解決這些混亂的狀況,有什麼解決的辦法,我想該是拿出Portal的時候了吧!
在一些比較知名的
Open Source Portal Server上,都有實作了不錯的權限控管機制(也許開始會有人說,那些權限管理的機制不符合我們的需要),不過試想一下,目前在業界中一些所謂的權限管理的分析是誰提出來的,通常來說是由使用者單位提出,然後由經驗不足,沒有OOAOOD能力的SASD所設計出來的(抱歉!不是一竿子打翻一船人,而是大多數情況皆是如此),而且大多數是由1~2個人就決定了權限的控管,那…各位覺得這樣的權限控管機制可靠嗎、彈性嗎、完完全全符合客戶需要嗎?

在開放原始碼的領域中,許多規格都是大家一起討論出來的,而在實作的Project上也進行了多次的進化,分析、分析再分析;抽象抽象再抽象。因此當我們真正認真去看這些看不懂程式碼的開放原始碼系統時將會發現,原來很多不了解的觀念都能得到解答,得到更佳的設計模式。

再 權限管理的部分亦是如此,經由多次進化的權限控管邏輯,在開放原始碼的社群中將演化成一種分析、設計模式,以應因未來各種不同的挑戰。因此這些權限控管機 制將會做到非常彈性,以符合大部分業界所需要,因此在我來說,我會建議,相關的分析、開發、設計人員盡其心力去了解這些設計理念,並將企業內部所需的權限 管理相關邏輯轉化為與其相近,你將會發現你得到的更多。而且還會發生一種有趣的狀況,以往當我們的企業邏輯做了修改(即便是小幅度的修正),程式卻幾乎難以進行維護,因為程式大部分是由資淺人員所開發,而開發過程中幾近是寫死的,高度藕合性、低度內聚力。維護非常困難。使用了開放原始碼的權限控管系統將會發現,程式很少修改,甚至於只需進行簡單的設定或完全不需調整即可符合需要,非常不可思議。

而網頁的LayerOut呢?之前我們都使用TilesSitemesh進行版面的設定與管理,但在Portal的使用上,LayerOut是由Portal進行統一的設定,不同的人登入可設定自定的版面設定,實際上的LayerOut應該來說…很少。將所有系統整合入Portal中只需登入一次即可使用各種不同的系統,這種夢想化的生活真是非常方便。

扯太多了,有時似乎文思泉湧就會扯出一大堆東西,回歸我所要表達的,Portal雖然方便,但開發Portlet並不容易,並且測試也不方便,每一次的測試都必須啟動一次Portal ServerPortal並不是小程式,每一次的啟動與關閉是非常花時間的,因此若有一個Portal平台啟動快速、方便測試相對的開發就會比較方便。而Pluto正符合我的需要,Pluto嚴格說並不能稱為Portal,只能稱為Portal最簡單的實作參考。但因為符合JSR-168的規範,我們可以將符合該規範的Portlet佈署在其上進行測試,當測試成功後再行佈署於所需的目的Portal Server上即可達成開發快速、測試方便的要求。

接著以下的觀念比較主觀,不認同的人可以不接受,就是事實上若使用不到所有的Portal的功能的話也可以將Portal降級使用,用來開發一般的系統,只是該系統中的所有程式基本上都是Portlet,因此未來當真正進入Portal時代時,程式只需小幅修正即可重用。

目前在我的王道中,Portal將會列入一個考量重點,並盡可能達到開發出的程式系統能符合下列要求:

  1. 在一般系統中能正常執行。

  2. Portal中加入相關繼承或Bridge即可在Portal上執行。

  3. 能在一般系統與Portal系統中進行功能性測試。


Read More......

2007年6月11日 星期一

在Maven2中取得Plug-in資訊

取得指定Plugin相關資訊
mvn help:describe -DgroupId=org.somewhere -DartifactId=some-plugin -Dversion=0.0.0
使用 full 參數顯示所有goal的參數資訊
使用 output 參數輸出至檔案

Example:
mvn help:describe -DgroupId=org.apache.maven.plugins -DartifactId=maven-idea-plugin -Dversion=2.0
or
mvn help:describe -DgroupId=org.apache.maven.plugins -DartifactId=maven-idea-plugin -Dfull=true -Doutput=plug.txt

簡易使用法:
mvn help:describe -Dplugin=plugin-prefix -Dfull=true

Example:
mvn help:describe -Dplugin=clean -Dfull=true

Read More......

2007年6月10日 星期日

金錢藍圖05 語言設定

在成長階段,親人總是說:「有錢人都很貪婪,他們靠窮人的血汗錢。賺的錢夠用就好,多賺就是豬了。」
由此我們可以猜出潛意識會上演戲碼。因為親人語言的制約而成為窮光蛋。
相信有錢人都很貪心。在心裡把有錢與貪婪畫上等號。
如果不想變成貪婪的人,潛意識裡就會不想變得富有。

當被問到是要選擇當有錢人呢?還是要選擇親人的認同,大部分人會選擇當有錢人…才怪!
人的心靈不是那樣運作的。當我們的潛意識必須在深植的情感和冷硬的邏輯之間做出抉擇,情感幾乎是每戰必勝的。

改變的步驟:修改語言程式
一、察覺:小時候聽過的所有描述金錢的話語。
二、理解:你認為這些說法如何影響你的財務生活。
三、畫清界限:那些關於金錢的想法只代表你所學來的東西,不是自已的想法。

Read More......