人民醫(yī)院性能測試工作情況報告

1、人民醫(yī)院電子簽章及文檔服務(wù)器系統(tǒng) 性能測試工作情況報告 王宗成二零一三年六月 1 測試背景1.1測試目標(biāo)對北京人民醫(yī)院電子簽章服務(wù)器及文檔服務(wù)器系統(tǒng)進(jìn)行性能測試，客觀的評估系統(tǒng)的性能現(xiàn)狀。1、開發(fā)正確有效的性能測試腳本，模擬用戶現(xiàn)場操作行為，作為測試有效實施的基礎(chǔ)；2、通過性能測試，評估在公司內(nèi)部模擬環(huán)境下，被測系統(tǒng)的各項性能指標(biāo)表現(xiàn)；3、驗證被測系統(tǒng)的系統(tǒng)業(yè)務(wù)處理能力和穩(wěn)定性，以及測試系統(tǒng)最高并發(fā)瓶頸是否能夠滿足在業(yè)務(wù)高峰期的性能要求，為被測系統(tǒng)上線提供參考依據(jù)。如不滿足，對性能瓶頸進(jìn)行定位分析，提供性能調(diào)優(yōu)建議。1.2測試人員王宗成2測試方法簡介2.1壓力測試實施基本流程：l 測試環(huán)境準(zhǔn)備

2、使用人民醫(yī)院版本的文檔服務(wù)器和公章5.0及weblogic10.3.2，保證軟件版本一致。不過，人民醫(yī)院項目比較特殊，電子簽章服務(wù)器做了個性化開發(fā)，并非通用的公章5.0版本。用戶現(xiàn)場使用HPProliantDL380高性能機架式服務(wù)器和磁盤陣列。由于硬件條件的限制，本次性能測試的硬件平臺跟實際用戶環(huán)境有差距。l 測試腳本開發(fā)：該測試程序覆蓋典型用戶的系統(tǒng)訪問模式所涉及的操作。腳本的開發(fā)是利用LoadRunner Vugen進(jìn)行腳本錄制，開發(fā)，調(diào)試的過程。l 測試執(zhí)行：本次性能測試的關(guān)鍵點即查看人民醫(yī)院業(yè)務(wù)系統(tǒng)在并發(fā)壓力下的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目以及在較大壓力下，系統(tǒng)的事務(wù)處理能力，并找出

3、各類事務(wù)的性能瓶頸。然后在指定的時間內(nèi)可對系統(tǒng)施實性能測試，性能測試執(zhí)行分為兩個階段：1、性能基準(zhǔn)測試：系統(tǒng)在輕負(fù)載環(huán)境下，評估當(dāng)前系統(tǒng)的性能表現(xiàn)，并作為后續(xù)壓力測試的性能比較基準(zhǔn)；2、負(fù)載壓力測試：模擬大批量并發(fā)業(yè)務(wù)，評估系統(tǒng)在高負(fù)載情況下系統(tǒng)的性能表現(xiàn)。l 測試結(jié)果分析報告：壓力測試結(jié)果經(jīng)過確認(rèn)有效后，將匯總壓力測試結(jié)果，形成性能測試分析報告。3測試環(huán)境3.1公司內(nèi)部模擬環(huán)境服務(wù)器地址配置說明硬件說明系統(tǒng)應(yīng)用服務(wù)器06操作系統(tǒng)：Red Hat Enterprise Linux Server 5.4（64位）中間件：Wenlogic10.3.2處理器：Intel Co

4、re i5 3.2 GHz，內(nèi)存：6GB數(shù)據(jù)庫服務(wù)器6Oracle 11g R2（64位）處理器：Intel Core2 2.5 GHz，內(nèi)存：4GB負(fù)載生成測試機 Load Runner 9.50處理器：Intel Core i5 2.5 GHz，內(nèi)存：4GB備注：本次壓力測試的網(wǎng)絡(luò)環(huán)境為內(nèi)部局域網(wǎng)。院方服務(wù)器端設(shè)備型號：名稱類型種類數(shù)量服務(wù)器HP ProLiant DL380G6機架式5磁盤陣列HP STORAGEWORKS HSV300（容量：450G*12）機架式13.2測試工具本次性能測試采用逐步增加壓力的壓力測試模式來執(zhí)行，查看應(yīng)用系統(tǒng)在各種壓力狀

5、況下的性能表現(xiàn)。采用HP公司的LoadRunner創(chuàng)建虛擬用戶腳本工具Virtual User Generator、創(chuàng)建、運行實際場景工具Controller、分析測試結(jié)果工具Analysis。采用QUEST公司的Spotlight on Oracle軟件來監(jiān)控Oracle數(shù)據(jù)庫，其優(yōu)點是實時準(zhǔn)確、界面直觀、操作配置簡單靈活、性能消耗可以限定在一個小范圍內(nèi)、不需要在被監(jiān)控設(shè)備部署Agent代理。采用VisualVM 監(jiān)控在 Java 虛擬機 (Java Virutal Machine, JVM) 上運行的 Java 應(yīng)用程序的詳細(xì)信息。4測試設(shè)計4.1性能需求依據(jù)現(xiàn)場實施人員提供性能需求：目前

6、醫(yī)生站目前有400個左右。建議相關(guān)并發(fā)數(shù)最少為400。系統(tǒng)上線后業(yè)務(wù)量大概一天在13000左右。4.2模擬用戶數(shù)依據(jù)現(xiàn)場實施人員提供的業(yè)務(wù)量數(shù)據(jù)和對系統(tǒng)上線后業(yè)務(wù)量預(yù)估，對當(dāng)前系統(tǒng)分別按400用戶、100用戶進(jìn)行壓力測試，以評估系統(tǒng)在不同壓力梯度情況下的性能表現(xiàn)。4.3測試模型建立此次性能測試的業(yè)務(wù)選擇，應(yīng)覆蓋各性能關(guān)鍵業(yè)務(wù)，依實施人員提供數(shù)據(jù)設(shè)計本次性能測試共兩類場景，即長時間低壓力并發(fā)和高負(fù)載并發(fā)兩類場景，前者采用100個用戶（Vuser）持續(xù)并發(fā)120分鐘來測試系統(tǒng)業(yè)務(wù)處理能力和穩(wěn)定性；后者采用400用戶并發(fā)5分鐘來測試系統(tǒng)最高并發(fā)瓶頸。除對兩類場景執(zhí)行的虛擬用戶和加壓時長做調(diào)整外，其他

7、的環(huán)境和數(shù)據(jù)都一樣。 選定如下業(yè)務(wù)：² login代表登錄的事務(wù)，對應(yīng)的時間表示登錄事務(wù)所需的最小時間、平均時間和最大時間；² stamp代表簽章事務(wù)，對應(yīng)的時間表示簽章事務(wù)所需的最小時間、平均時間和最大時間；² upload 代表上傳事務(wù)，對應(yīng)的時間表示完成上傳事務(wù)所需的最小時間、平均時間和最大時間；² logout代表注銷的事務(wù)，對應(yīng)的時間表示注銷事務(wù)所需的最小時間、平均時間和最大時間；業(yè)務(wù)場景一1、 模擬用戶數(shù)：1002、 Pacing：130分鐘；3、 當(dāng)所有用戶加載完畢后連續(xù)運行120分鐘；4、 用戶調(diào)度策略：每5秒啟動1個虛擬用戶。業(yè)務(wù)場景二

8、1、 模擬用戶數(shù)：4002、 Pacing：45分鐘；3、 當(dāng)所有用戶加載完畢后連續(xù)運行5分鐘；4、 用戶調(diào)度策略：每5秒啟動1個虛擬用戶。5測試結(jié)果分析 5.1業(yè)務(wù)場景一測試結(jié)果5.1.1平均響應(yīng)時間測試使用了400個并發(fā)用戶，并發(fā)用戶的啟動信息如下：各事務(wù)的響應(yīng)時間 （秒）ColorScale事務(wù)最小平均最大1登錄0.0080.0423.7151登出0.0040.0212.4091簽章0.050.2047.3891上傳0.0390.17616.522各事務(wù)的平均響應(yīng)時間圖：平均響應(yīng)時間分析：從上圖中可以看出，各操作的響應(yīng)時間隨著用戶數(shù)的增加呈平穩(wěn)趨勢，都沒有超過1秒，在可接受范圍內(nèi)。5.1

9、.2系統(tǒng)處理能力測試中，每秒的點擊率如下：測試中吞吐量如下：事務(wù)總體分析圖表：ColorScaleMeasurement1Fail1Pass系統(tǒng)處理能力分析：可以看出，系統(tǒng)處理能力隨用戶數(shù)的增加呈線性上升趨勢，即未出現(xiàn)性能瓶頸，100用戶時系統(tǒng)業(yè)務(wù)處理能力達(dá)到每小時3800筆。 24小時可處理91000筆。業(yè)務(wù)量分析依據(jù)用戶提供的數(shù)字，系統(tǒng)上線后訪問業(yè)務(wù)量期望在0:00-24:00這一時間段內(nèi)達(dá)到13000。根據(jù)這樣的業(yè)務(wù)量，采用二八原則進(jìn)行業(yè)務(wù)量與業(yè)務(wù)時間段的重新規(guī)劃，即為80%的業(yè)務(wù)量在20%的時間內(nèi)完成。那么1.3萬訪問量的80%即為1.04萬，而24個小時的20%即為4.8小時。故本次

10、測試，如果性能滿足4.8小時內(nèi)完成1.04萬的業(yè)務(wù)訪問量，即每小時2170的業(yè)務(wù)訪問量為測試通過。而本次測試100用戶時系統(tǒng)處理能力達(dá)到每小時3800筆，滿足并超出客戶提出的上線后每日完成1.3萬的處理能力。5.1.3資源利用率ColorScaleMeasurementMin.Ave.Max.100Average load (Unix Kernel Statistics):060.00.0740.46910CPU Utilization (Unix Kernel Statistics):060.01.29114.6490.1Paging rate

11、 (Unix Kernel Statistics):060.0232.969735.333資源利用率分析：在上圖中我們可以看出CPU、內(nèi)存利用率均在正常范圍內(nèi)，系統(tǒng)表現(xiàn)良好。5.2業(yè)務(wù)場景二測試結(jié)果5.2.1平均響應(yīng)時間測試使用了400個并發(fā)用戶，并發(fā)用戶的啟動信息如下：各事務(wù)的響應(yīng)時間 （秒）ColorScale事務(wù)最小平均最大1登錄0.0047.603116.1651登出0.0050.76536.1291簽章0.04211.705149.4361上傳0.0313.671109.366各事務(wù)的平均響應(yīng)時間圖：平均響應(yīng)時間分析：可以看出隨著測試的進(jìn)行，事務(wù)相應(yīng)時間逐漸增

12、大，其中蓋章事務(wù)響應(yīng)時間最長。12分鐘后最終導(dǎo)致超時而失敗。5.2.2系統(tǒng)處理能力測試中，每秒的點擊率如下：測試中吞吐量如下：系統(tǒng)處理能力分析：根據(jù)上面兩組數(shù)據(jù)，即：每秒的點擊率和吞吐量，可以看出，在測試執(zhí)行開始約10分鐘以后，用戶達(dá)到200以上，業(yè)務(wù)系統(tǒng)用戶登錄和簽章的并發(fā)數(shù)量不斷在增加，但是用戶登錄后的數(shù)據(jù)吞吐量卻變化不大，這樣將最終導(dǎo)致大量的用戶登錄因為事務(wù)處理超時而失敗。測試過程中高負(fù)載下Weblogic后臺發(fā)現(xiàn)有以下錯誤：Ø 報錯1：/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/

13、usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)Ø 報錯2：<2013-5

14、-31 下午01時23分50秒 CST> <Error> <HTTP> <BEA-101104> <Servlet execution in servlet context "ServletContext17976572app:DocServer module:webroot path:/DocServer spec-version:2.5" failed, .ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes i

15、nstead of stated: '7420' bytes.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '7420' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.Ser

16、vletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Trunca

17、ted. see log file for complete stacktrace> <2013-5-31 下午01時23分50秒 CST> <Error> <HTTP> <BEA-101083> <Connection failure.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2721' bytes.at ernal

18、.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletReq

19、uestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Truncated. see log file for complete stacktrace> Ø 報錯3：0x0a404c00 JavaThread "ACTIVE ExecuteThread: '100' for queue: 'weblogic.kernel.Default (self-tuning)'" daem

20、on _thread_blocked, id=23175, stack(0x31176000,0x311c7000) 0x0a403400 JavaThread "ACTIVE ExecuteThread: '99' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon _thread_blocked, id=23174, stack(0x311c7000,0x31218000) 0x0a401c00 JavaThread "ACTIVE ExecuteThread:

21、'98' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon _thread_blocked, id=23173, stack(0x31218000,0x31269000)5.2.3調(diào)優(yōu)設(shè)置1、 針對報錯1，協(xié)調(diào)開發(fā)人員關(guān)閉后臺日志寫入和檢查寫文件后文件關(guān)閉情況。2、 針對報錯2，協(xié)調(diào)開發(fā)人員，開發(fā)人員未能查明原因。3、 針對報錯3，當(dāng)系統(tǒng)壓力超過測試最大壓力時，所有線程都被占用，引起線程阻塞。而JDBC連接使用服務(wù)器線程來執(zhí)行工作，沒有了線程就不能處理新的請求，嚴(yán)重會引起weblogi

22、c掛起現(xiàn)象。4、 增大WebLogic線程池大小，WebLogic10的線程池可以根據(jù)系統(tǒng)吞吐情況，自動調(diào)整大小。設(shè)置調(diào)整臨界值為最小100，最大500。5、 增大Weblogic JVM內(nèi)存，Weblogic的啟動內(nèi)存默認(rèn)配置為-Xms32m -Xmx256m，通過修改commEnv.sh提高JVM內(nèi)存。設(shè)置為最大1536M。6、 修改oracle的process為1000。 oracle數(shù)據(jù)庫和Weblogic的連接池的配置相關(guān)，所有Weblogic節(jié)點的連接池最大連接數(shù)之和不能大于oracle的最大線程數(shù)。 7、 將數(shù)據(jù)庫連接池最小連接數(shù)設(shè)置為20。連接池的最大連接數(shù)設(shè)為200。5.3場

23、景二調(diào)優(yōu)后測試結(jié)果5.3.1平均響應(yīng)時間第二次測試經(jīng)過了第一次的調(diào)優(yōu)，并且使用了Spotlight on Oracle來監(jiān)控Oracle數(shù)據(jù)庫，采用VisualVM 監(jiān)控JVM。運行并發(fā)用戶400如下圖：各類事務(wù)的平均響應(yīng)時間如下表：（單位：秒）ColorScale事務(wù)最小平均最大1登錄0.0034.25186.5841登出0.0040.04621.1231簽章0.0242.5122.3111上傳0.0231.29830.789事務(wù)響應(yīng)時間時序圖如下：平均響應(yīng)時間分析：從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有事務(wù)的平均響應(yīng)時間都在平穩(wěn)增加幅度較小，只有蓋章和登錄事務(wù)的耗時維持在較高水平

24、。5.3.2系統(tǒng)處理能力測試中每秒的點擊率如下：系統(tǒng)處理能力分析從圖中可以看出，系統(tǒng)處理能力隨著并發(fā)用戶數(shù)量的不斷增加，直到并發(fā)用戶數(shù)不再增加，這時候系統(tǒng)處理能力穩(wěn)定保持在峰值并出現(xiàn)一定波動。5.3.3使用Spotlight實時監(jiān)控Oracle性能SESSION監(jiān)控從圖中可以看到，SID為409，用戶名為root的SESSION其當(dāng)前日志讀為每秒231.93個塊數(shù)，排名最前。圖中監(jiān)控性能消耗靠前的SQL語句截圖：整個場景運行中出現(xiàn)的性能消耗靠前的其他SQL語句此SQL為文檔服務(wù)器為每一筆事務(wù)向數(shù)據(jù)庫loginfo表內(nèi)寫入交易日志，若無存在必要建議優(yōu)化，長時間會引起數(shù)據(jù)庫表容量堆積過大。5.3.

25、4使用VisualVM監(jiān)控JVM：Weblogic JVM監(jiān)控分析：從圖中上部Heap圖可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，used heap的折線圖呈鋸齒狀，說明垃圾對象及時被回收了，內(nèi)存得以釋放，沒有內(nèi)存泄漏。如果used heap的值只增不減說明存在內(nèi)存泄漏了，如果超過heap size的值，會報內(nèi)存溢出的錯誤。圖中下部Thread圖可以看出，線程做出了自調(diào)整增大，隨著負(fù)載增大，最大線程自調(diào)優(yōu)至200，一般情況其上限是每個CPU對應(yīng)50個線程，其按照CPU個數(shù)線性增長。6測試結(jié)論通過分析測試結(jié)果，可以得出以下結(jié)論，在公司內(nèi)部模擬環(huán)境下：1、測試系統(tǒng)的業(yè)務(wù)處理能力滿足每日業(yè)務(wù)量要求，長時

26、間反復(fù)運行中，系統(tǒng)未出現(xiàn)不良反應(yīng)，包括cpu、內(nèi)存占用過高、內(nèi)存泄漏等，系統(tǒng)響應(yīng)時間令人滿意，系統(tǒng)穩(wěn)定性比較可靠。能夠滿足系統(tǒng)上線后一天在13000左右業(yè)務(wù)量的要求。2、測試系統(tǒng)用戶并發(fā)量在300，能正常工作。當(dāng)并發(fā)用戶達(dá)到400時，部分用戶需要花10秒以上時間簽章和登錄，依據(jù)測試300到400用戶的情況下系統(tǒng)表現(xiàn)情況。結(jié)果發(fā)現(xiàn)系統(tǒng)在接近400時出現(xiàn)連接超時等現(xiàn)象，在本次測試環(huán)境下系統(tǒng)滿足并發(fā)300用戶。7存在問題及建議測試過程中高負(fù)載下Weblogic后臺發(fā)現(xiàn)有以下信息：Ø 報錯1：<2013-6-3 下午02時44分15秒 CST> <Critical>

27、<Server> <BEA-002616> <Failed to listen on channel "Default" on 06:7001, failure count: 1, failing for 0 seconds, .SocketException: Too many open files> Ø 報錯2：<2013-5-31 下午01時23分50秒 CST> <Error> <HTTP> <BEA-101104> <Servlet exec

28、ution in servlet context "ServletContext17976572app:DocServer module:webroot path:/DocServer spec-version:2.5" failed, .ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '7420' bytes.ProtocolException: Didn't meet stated Conte

29、nt-Length, wrote: '0' bytes instead of stated: '7420' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at weblogic.servlet

30、.internal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Truncated. see log file for complete stacktrace> <2013-5-31 下午01時23分50秒 CST> <Er

31、ror> <HTTP> <BEA-101083> <Connection failure.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2721' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at weblo

32、ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(Execu

33、teThread.java:201)Truncated. see log file for complete stacktrace> 1、針對滿負(fù)載運行下login事務(wù)耗時大量增加的情況，請依據(jù)此weblogic后臺報錯信息排查：<2013-6-3 下午02時44分15秒 CST> <Critical> <Server> <BEA-002616> <Failed to listen on channel "Default" on 06:7001, failure count: 1, failing for 0 seconds, .SocketException: Too many open files> 2、對于<BEA-101083>，此后臺報錯協(xié)調(diào)開發(fā)人員未能查清