性能測試實(shí)例講解

1、Hundsun Technologies Inc. | 性能測試實(shí)例講解性能測試實(shí)例講解 Hundsun Technologies Inc. |運(yùn)行場景前準(zhǔn)備工作運(yùn)行場景前準(zhǔn)備工作1.測試目標(biāo)2.測試用例3.獨(dú)立性能測試環(huán)境（包括壓力測試機(jī)在內(nèi)）4.各服務(wù)器硬件配置5.各服務(wù)參數(shù)配置6.數(shù)據(jù)庫基礎(chǔ)數(shù)據(jù)量Hundsun Technologies Inc. |一一、數(shù)據(jù)庫、數(shù)據(jù)庫SQL效率導(dǎo)致瓶頸效率導(dǎo)致瓶頸Hundsun Technologies Inc. |數(shù)數(shù)米基金米基金網(wǎng)拓?fù)渚W(wǎng)拓?fù)鋱D和硬件統(tǒng)計(jì)圖和硬件統(tǒng)計(jì)序號(hào)名 稱IP機(jī)器配置1.webloigc服務(wù)器2CPU：Int

2、el(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核內(nèi)存：8G硬盤：400G網(wǎng)卡：千兆網(wǎng)卡操作系統(tǒng)：LINUX 64位1.tuxedo服務(wù)器1CPU：Intel(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核內(nèi)存：8G硬盤：400G網(wǎng)卡：千兆網(wǎng)卡操作系統(tǒng)：LINUX 64位1.oracle服務(wù)器9CPU：Intel(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核內(nèi)存：16G硬盤：60G網(wǎng)卡：千兆網(wǎng)卡操作系統(tǒng)：LINUX 64位Hundsun Technologies Inc. |

3、數(shù)數(shù)米基金網(wǎng)性能測試參數(shù)配置米基金網(wǎng)性能測試參數(shù)配置Weblogic:-Xms5122m-Xmx5122m-XX:MaxPermSize=1024m-Dweblogic.threadpool.MinPoolSize=100-Dweblogic.threadpool.MaxPoolSize=500Tuxedo:MAXACCESSERS256MAXSERVERS100MAXSERVICES200Hundsun Technologies Inc. |數(shù)數(shù)米基金米基金網(wǎng)交易記錄查詢網(wǎng)交易記錄查詢LRLR結(jié)果結(jié)果在日志模式為info級(jí)別的前提下，模擬用戶每隔5秒向后臺(tái)發(fā)送交易記錄查詢請(qǐng)求（查詢的時(shí)間段為

4、1年，返回結(jié)果為313條記錄）。當(dāng)Vuser14時(shí)，響應(yīng)時(shí)間基本維持在8-10秒之間，TPS也達(dá)到最大將近1.2筆/秒；Vuser繼續(xù)增加，TPS水平保持不變而響應(yīng)時(shí)間大幅度上升，當(dāng)Vuser=30時(shí)，響應(yīng)時(shí)間達(dá)到了將近20秒。Hundsun Technologies Inc. |數(shù)數(shù)米基金米基金網(wǎng)交易記錄查詢瓶頸網(wǎng)交易記錄查詢瓶頸分析分析 我們可以看到得到的測試結(jié)果并不是很理想，那么接下來我們需要分析下到底瓶頸出現(xiàn)在哪里。 1. 我們將log級(jí)別設(shè)置為error級(jí)別查看性能是否有提升。測試結(jié)果是跟debug級(jí)別時(shí)的結(jié)果大致相同，所不同的只是weblogic服務(wù)器的磁盤IO從7%下降到了3%左

5、右。更改log級(jí)別對(duì)交易記錄查詢性能提升不大。Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析 2.我們繼續(xù)觀察服務(wù)器硬件在場景運(yùn)行期間的性能情況。Weblogic服務(wù)器和tuxedo服務(wù)器硬件性能在場景運(yùn)行期間表現(xiàn)正常，這里不再贅述，我們這里重點(diǎn)說明下oracle服務(wù)器的硬件性能情況：場景運(yùn)行期間的CPU平均值維持在100%： Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析 3.可以看出數(shù)據(jù)庫CPU壓力過大可能是制約系統(tǒng)性能的瓶頸點(diǎn)，那么為什么數(shù)據(jù)庫CPU壓力

6、在TPS很低的情況下會(huì)如此之大？我們先看看應(yīng)用服務(wù)層表現(xiàn)是否正常，weblogic的JVM堆內(nèi)存在2G-3.5G之間波動(dòng)，GC較正常，峰值線程為261個(gè)，加載類穩(wěn)定在19239個(gè)，消耗的CPU在15%-20%之間。 Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析監(jiān)控weblogic的熱點(diǎn)發(fā)現(xiàn)92.6%的時(shí)間消耗在wait()方法上，追蹤調(diào)用方法發(fā)現(xiàn)耗時(shí)主要在socket的read上： Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析 4. 我們先來看下ORACL

7、E數(shù)據(jù)庫的AWR報(bào)告，DB Time很大，數(shù)據(jù)庫很繁忙，這里我們從數(shù)據(jù)庫服務(wù)器的硬件已經(jīng)看出： Load profile和SGA的各種命中率都正常：Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析top 5 事件 CPU time是第一位： 有兩條SQL語句執(zhí)行數(shù)量明顯大于其他SQL語句，占用了CPU總耗時(shí)的83.2%Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析我們發(fā)現(xiàn)調(diào)用直銷查詢服務(wù)返回有條數(shù)限制（這里限制為50條），所以返回313條記錄要調(diào)用查詢7次，造成

8、響應(yīng)時(shí)間和oracle服務(wù)器的cpu資源大量被消耗。這兩條SQL語句一個(gè)查條數(shù)，一個(gè)查數(shù)據(jù)，具體如下:可以看到其結(jié)構(gòu)非常復(fù)雜，嵌套層數(shù)很多，且有大量嵌套循環(huán)，而且每次事務(wù)要查詢7次，難怪每次查詢的響應(yīng)時(shí)間會(huì)這么長。 Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析那么我們是否可以采用分頁顯示呢？直銷查詢服務(wù)返回既然有50條的數(shù)限制，那么我們就模擬每次只查詢50條記錄的場景，即每次查詢只調(diào)用一次后臺(tái)SQL查詢。測試結(jié)果是在無壓力情況下，查詢一次響應(yīng)時(shí)間在1.8-2秒左右；當(dāng)模擬用戶數(shù)達(dá)到40個(gè)時(shí)，后臺(tái)處理速度達(dá)到最大3筆/秒，響應(yīng)

9、時(shí)間在6秒左右，隨著模擬用戶繼續(xù)增加處理速度基本不變，響應(yīng)時(shí)間大幅度增加。后臺(tái)weblogic的CPU壓力平均22.3%左右，tuxedo服務(wù)器CPU壓力平均值為6.2%，數(shù)據(jù)庫服務(wù)器CPU壓力平均值為47%左右。可以看到每次查詢數(shù)量減小后，無論響應(yīng)時(shí)間和服務(wù)器CPU壓力等性能提升都比較明顯。查詢修改為分頁顯示會(huì)提高不少性能。 Hundsun Technologies Inc. |數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析數(shù)米基金網(wǎng)交易記錄查詢瓶頸分析優(yōu)化建議：1.從短期來看，我們可以在硬件上設(shè)置數(shù)據(jù)庫集群來緩解數(shù)據(jù)庫服務(wù)器的壓力，增大可以接受的訪問系統(tǒng)的人數(shù)；建立緩存服務(wù)來減少對(duì)歷史數(shù)據(jù)的查詢次數(shù)；查詢

10、修改為分頁顯示也會(huì)提高不少性能。2.要從根本上優(yōu)化此測試用例的性能，癥結(jié)還是在oracleAWR報(bào)告部分提到的兩條SQL，它們被多次調(diào)用，而且這兩條SQL結(jié)構(gòu)非常復(fù)雜，嵌套層數(shù)很多，建議最好請(qǐng)DBA協(xié)助對(duì)此SQL進(jìn)行改進(jìn)。 Hundsun Technologies Inc. |二二、數(shù)據(jù)庫行鎖導(dǎo)致瓶頸、數(shù)據(jù)庫行鎖導(dǎo)致瓶頸Hundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購LRLR結(jié)果結(jié)果 Loadrunner模擬70個(gè)虛擬用戶無等待時(shí)間向后臺(tái)發(fā)送認(rèn)購請(qǐng)求，場景運(yùn)行期間后臺(tái)TPS最大690筆/秒，平均650筆/秒，平均每筆認(rèn)購的響應(yīng)時(shí)間為0.1秒。如果再增大

11、壓力，后臺(tái)的TPS不會(huì)再增大，說明后臺(tái)的TPS已經(jīng)達(dá)到最大的處理能力。Hundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分析 以下是場景運(yùn)行期間各服務(wù)器的硬件性能統(tǒng)計(jì)。單從硬件性能統(tǒng)計(jì)來看，硬件表現(xiàn)都很正常，不存在瓶頸。Hundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分析 我們更進(jìn)一步去看各服務(wù)是否存在瓶頸，場景運(yùn)行期間我們通過HSADMIN監(jiān)控AS和LS的接收和應(yīng)答包，發(fā)現(xiàn)無請(qǐng)求積壓：Hundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分

12、析 進(jìn)而我們繼續(xù)觀察數(shù)據(jù)庫，通過ORACLE AWR報(bào)告發(fā)現(xiàn)數(shù)據(jù)庫TOP5事件中行鎖占用了數(shù)據(jù)庫運(yùn)行時(shí)間的82%，已經(jīng)存在很嚴(yán)重的行鎖事件：而通過行鎖事件統(tǒng)計(jì)表來看基本所有的行鎖都發(fā)生在prodcontrol表中：Hundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分析 進(jìn)而我們繼續(xù)觀察數(shù)據(jù)庫，通過ORACLE AWR報(bào)告發(fā)現(xiàn)數(shù)據(jù)庫TOP5事件中行鎖占用了數(shù)據(jù)庫運(yùn)行時(shí)間的82%，已經(jīng)存在很嚴(yán)重的行鎖事件：而通過行鎖事件統(tǒng)計(jì)表來看基本所有的行鎖都發(fā)生在prodcontrol表中：Hundsun Technologies Inc. |多金融證券理財(cái)

13、認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分析 而通過TOP SQL統(tǒng)計(jì)表我們發(fā)現(xiàn)耗時(shí)的SQL語句也正是關(guān)于prodcontrol表的查詢語句：SELECT UP_LIMITED, CURR_LIMITED FROM PRODCONTROL A WHERE A.PROD_CODE = :B3 AND A.PRODTA_NO = :B2 AND A.ORGAN_FLAG =! AND A.ENTRUST_WAY =! AND (A.BUSINESS_FLAG =:B1 ) FOR UPDATEHundsun Technologies Inc. |多金融證券理財(cái)認(rèn)購多金融證券理財(cái)認(rèn)購瓶頸分析瓶頸分析 我們

14、知道for update語句的效果相當(dāng)于啟動(dòng)了一個(gè)會(huì)話級(jí)別的事務(wù)，在對(duì)應(yīng)的數(shù)據(jù)表上加入一個(gè)數(shù)據(jù)表級(jí)共享鎖，同時(shí)在對(duì)應(yīng)的數(shù)據(jù)行中加入獨(dú)占鎖；而如果此時(shí)有另一個(gè)會(huì)話想獲取對(duì)應(yīng)數(shù)據(jù)行的獨(dú)占權(quán)限，都會(huì)block在那里等待鎖的釋放。這也是為什么場景運(yùn)行期間數(shù)據(jù)庫行鎖事件占了TOP事件的第一位，而這也就是本功能點(diǎn)的瓶頸所在了。Hundsun Technologies Inc. |三三、服務(wù)內(nèi)存泄露導(dǎo)致瓶頸、服務(wù)內(nèi)存泄露導(dǎo)致瓶頸Hundsun Technologies Inc. |證證通開放平臺(tái)架構(gòu)通開放平臺(tái)架構(gòu) Hundsun Technologies Inc. |證通開放平臺(tái)訪問首頁證通開放平臺(tái)訪問首頁

15、LRLR結(jié)果結(jié)果 Loadrunner模擬50個(gè)虛擬用戶無等待時(shí)間向后臺(tái)發(fā)送訪問首頁請(qǐng)求，場景運(yùn)行期間后臺(tái)TPS達(dá)到750筆/秒，平均每筆事務(wù)的響應(yīng)時(shí)間為0.065秒。如果再增大壓力，后臺(tái)的TPS不會(huì)再增大而響應(yīng)時(shí)間在不斷增大，說明后臺(tái)的TPS已經(jīng)達(dá)到最大的處理能力。當(dāng)場景運(yùn)行至6分30秒時(shí)，場景的TPS突然降低至幾筆/秒，響應(yīng)時(shí)間猛增至5秒左右。Hundsun Technologies Inc. |證通開放平臺(tái)訪問首頁瓶頸證通開放平臺(tái)訪問首頁瓶頸分析分析以下是場景運(yùn)行期間各服務(wù)器的硬件性能統(tǒng)計(jì)。單從硬件性能統(tǒng)計(jì)來看，門戶服務(wù)器的CPU壓力基本達(dá)到極限，這也是為什么訪問首頁功能點(diǎn)的TPS在達(dá)到750筆/秒后不再上升的原因。但是在場景運(yùn)行一段時(shí)間后，TPS突然降低至幾筆/秒，單從硬件性能表現(xiàn)上還無法查明原因。 Hundsun Technologies Inc. |證通開放平臺(tái)訪問首頁瓶頸證通開放平臺(tái)訪問首頁瓶頸分析分析我們再看TOMCAT服務(wù)的表現(xiàn)，CPU壓力占用服務(wù)器CPU90%左右；堆內(nèi)存消耗從初始化開始的500MB隨著場景增大，最大達(dá)到堆內(nèi)存的最