ArcGIS Server 性能測試報(bào)告

《ArcGIS Server 性能測試報(bào)告》由會員分享，可在線閱讀，更多相關(guān)《ArcGIS Server 性能測試報(bào)告（12頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

1、 ArcGIS Server 性能測試方法及結(jié)果報(bào)告 （僅限內(nèi)部參考） 測試人員 許曉輝 文檔 測試目標(biāo) 初步了解ArcGIS Server的性能，探索理想的ArcGIS Server部署方法。比較ArcGIS Server與ArcIMS的響應(yīng)速度。力求用實(shí)用的方法，獲得第一手?jǐn)?shù)據(jù)，為ArcGIS Server的推廣提供可參考得依據(jù)。 測試環(huán)境 參與測試的有4臺微機(jī)： 機(jī)器名 硬件配置 相關(guān)軟件 PSDServer Intel Core2 CPU 雙核2.4GHZ ， 3.5G memory Windows 2003 Server, ARC

2、IS Server 9.2 SP3, ArcSDE 9.2 SP3, Oracle10g，ArcGIS Server 9.2 not net ADF SP3, VS2005. Esri-nobody Intel Core2 CPU 雙核 1.83GHz, 2G memeory Windows XP sp2, ArcGIS Server 9.2 SP2 xxh Intel CPU 1.66GHz ,雙核，2G memory Windows XP sp2, ArcGIS Server 9.2 SP2 Esri-test3 AMD Opteron (tm) Processor 144

3、, 2.4GHZ, 2G memory Microsoft Application Center Test (MS ACT) 1.0 測試方法及工具簡介 測試數(shù)據(jù)源 地圖文件beijingtest.mxd，按照制圖要求，有渲染，有最大最小比例以及較多的標(biāo)注，但標(biāo)注不使用特殊效果，以減少服務(wù)器負(fù)擔(dān)。地圖數(shù)來源于PSDServer上的ArcSDE的北京數(shù)據(jù), 數(shù)據(jù)比較多的圖層有道路圖層（25343條記錄，主要單位（14500條記錄）和居民區(qū)圖層（約50萬條記錄）。 將此地圖發(fā)布到為ArcGIS Server的service，名為beijingtest, 并做了10級cache.

4、 地圖文件Road.mxd, 包含一層數(shù)據(jù)，即PSDServer上ArcSDE中的北京道路圖層，發(fā)布為ArcGIS Server的Service，名為Road, 不作cache. 后面測試都是基于這兩個服務(wù)展開。 測試工具 傳統(tǒng)的網(wǎng)站（如ArcIMS HTML Viewer）都是無狀態(tài)的，即每次Http請求之間沒有狀態(tài)要傳遞，那么用Load runner等工具可以錄制測試腳本，進(jìn)行測試。 但ArcGIS 的 ADF是有狀態(tài)的，狀態(tài)保存在Session里面，現(xiàn)有的錄制軟件無法錄制Session中的狀態(tài)。 HTML 服務(wù)器 客戶端 HTTP HTTP Session

5、 .Net ADF SessionID SessionID 所以只能通過遍程序來實(shí)現(xiàn)動態(tài)SessionID的獲取和傳遞。我們選擇Microsoft Application Center Test 1.0作為測試軟件。 通過fiddler2.0來截取原始的Http請求，轉(zhuǎn)換后，在MS ACT中調(diào)試運(yùn)行。 通過調(diào)試，在ACT中將一些無關(guān)請求去掉，例如開始頁中一些無用卻耗時的請求，力求使得測試貼近實(shí)際使用情況。 測試腳本 地圖操作：起始頁，放大X2 ，漫游X 2，全圖。共6個操作 Think time設(shè)置為4到8秒的一個隨機(jī)數(shù)，大約為6秒。 測試的網(wǎng)

6、站基于Dot net ADF，通過VS2005進(jìn)行一些修改。 計(jì)算每次地圖操作所用時間的方法： t=迭代時間，m=迭代次數(shù), u=客戶端數(shù)量, tt=腳本中think time的次數(shù), tt_v=think time的值, a=腳本中地圖操作的數(shù)量 每次地圖操作平均響應(yīng)時間 ＝ (t*u-m*tt*tt_v) / (m*a） 測試項(xiàng)目 注意：測試中所有與時間有關(guān)的項(xiàng)目全部以秒為單位。 ArcGIS Server 不用Cache 技術(shù)的情況下的性能： 說明：為了測試沒有Cache情況下服務(wù)器負(fù)載和響應(yīng)情況，將beijingtest的cache去掉。并將其初始最小in

7、stance設(shè)置為20。 結(jié)果：30個并發(fā)用戶CPU達(dá)到了97％。所以就測試到30個用戶。 客戶端響應(yīng)情況： 用戶數(shù) 迭代時間 地圖操作響應(yīng)速度 10 300 2.196721311 20 300 4.989010989 30 300 10.48351648 服務(wù)器的資源使用情況： 用戶數(shù) 服務(wù)器CPU 服務(wù)器網(wǎng)絡(luò) 內(nèi)存 10 63 180000 63 20 90 262000 63 30 97 253000 64 20個并發(fā)時服務(wù)器的CPU＆內(nèi)存： 20個并發(fā)時服務(wù)器的各個進(jìn)程使用CPU和內(nèi)存情況：

8、 ArcGIS Server 使用Cache 情況下的性能： 說明：測試Beijingtest服務(wù)，最小進(jìn)程數(shù)設(shè)置為20。啟用cache。 結(jié)果：響應(yīng)明顯加快，數(shù)據(jù)如下： 客戶端響應(yīng)情況： 用戶數(shù) 迭代時間 地圖操作響應(yīng)速度 10 180 1.317073171 20 180 1.5 30 180 1.894736842 40 300 1.547169811 50 300 2.333333333 60 300 4.309278351 70 300 5.98630137 80 300 7.422818792 90

9、300 10.30434783 100 300 10.66666667 服務(wù)器的資源使用情況： 用戶數(shù) 服務(wù)器CPU 服務(wù)器網(wǎng)絡(luò) 內(nèi)存 10 17 188000 57 20 40 500000 57.7 30 50 723000 58.9 40 66 1070000 60 50 73 1130000 59 60 81 1170000 60 70 85 1280000 60 80 86 1100000 60.2 90 88 1110000 61 100 89 1200000 61 80個用

10、戶的情況下CPU＆內(nèi)存使用情況： 80個用戶的情況下各個進(jìn)程使用cpu＆內(nèi)存的情況： ArcGIS Server在多個服務(wù)的情況下（底圖是Cache的）的性能： 說明：用帶cache的beijingtest服務(wù)作為底圖，以Road服務(wù)作為浮動圖層。這樣可以模擬那些需要編輯等高級功能的圖層。 結(jié)果： 客戶端響應(yīng)情況： 用戶數(shù) 迭代時間 地圖操作響應(yīng)速度 10 300 2.064516 20 300 6.5 30 300 10.66667 服務(wù)器的資源使用情況： 用戶數(shù) 服務(wù)器CPU 服務(wù)器網(wǎng)絡(luò)(Byte/s) 內(nèi)存(

11、%) 10 60 380000 59 20 90 500000 60 30 95 580000 60 30個用戶的時候服務(wù)器CPU＆內(nèi)存使用情況： 擴(kuò)展ArcGIS Server SOC對性能的影響： 說明：將機(jī)器xxh和 Esri-nobody作為PSDServer的SOC，同事PSDServer上保留SOC但最多限制25個instance。將Beijingtest初始的instance數(shù)量設(shè)置為30。 這樣，PSDServer就做為WebServer, ArcSDE Server, 數(shù)據(jù)庫服務(wù)器，SOM存在。 結(jié)果： 服務(wù)器的資源

12、使用情況： 用戶數(shù) 地圖操作響應(yīng)速度 (典型部署方式) 地圖操作響應(yīng)速度 (分布式部署) 50 2.33 1.18 60 4.31 1.65 70 5.99 2.22 80 7.42 2.55 90 10.3 4 100 10.67 4.87 服務(wù)器的資源使用情況： 　 用戶數(shù) 典型式 分布式 CPU% 50 73 som+soc:67,soc1:25,soc2:28 60 81 som+soc:76,soc1:30,soc2:35 70 85 som+soc:76,soc1:34,soc2:40 80

13、 86 som+soc:86,soc1:35,soc2:41 90 88 som+soc:84,soc1:35,soc2:38 100 89 som+soc:87,soc1:37,soc2:39 網(wǎng)絡(luò) Mb/s 50 9.04 15.68 60 9.36 19.2 70 10.24 21.6 80 8.8 22.4 90 8.88 20 100 9.6 21.6 ArcGIS Server與ArcIMS的性能對比： 說明：使用同樣的數(shù)據(jù)源和地圖文檔beijingtest.mxd。ArcIMS使用ArcMapServer，并用ArcIM

14、S Web Manager for Microsoft dot Net Framework發(fā)布一個應(yīng)用。采用和ArcGIS Server同樣的方法測試。ArcIMS版本為9.2 SP3。ArcIMS配置10個instances. ArcGIS Server 初始配置20個instance. 雖然instance數(shù)量不同，但根據(jù)經(jīng)驗(yàn)不會影響結(jié)果。因?yàn)樽罱K限制結(jié)果的是系統(tǒng)資源而不是instance的數(shù)量。 結(jié)果： 服務(wù)器的資源使用情況： 　 用戶數(shù) 地圖操作響應(yīng)速度 服務(wù)器CPU 服務(wù)器網(wǎng)絡(luò) 服務(wù)器內(nèi)存 ArcIMS 10 1.936507937 55 6100

15、0 50 20 4 87 92500 52 30 8.285714286 97 95000 50 ArcGIS Server (Cache) 10 1.317073171 17% 188000 57 20 1.5 40 500000 57.7 30 1.894736842 50 723000 58.9 40 1.547169811 66 1070000 60 50 2.333333333 73 1130000 59 60 4.309278351 81 1170000 60 70 5.98630137 85

16、 1280000 60 80 7.422818792 86 1100000 60.2 90 10.30434783 88 1110000 61 100 10.66666667 89 1200000 61 ArcGIS Server (No Cache) 10 2.196721311 63 180000 63 20 4.989010989 90 262000 63 30 10.48351648 97 253000 64 結(jié)果分析 不用Cache，用Cache做底圖再用一個非cache的服務(wù)做浮動圖層，或者用ArcIMS A

17、rcMapServer，這三種情況下最多30個用戶就可以讓PSDServer的CPU達(dá)到90％以上，這時如果再加更多的用戶只能導(dǎo)致響應(yīng)時間不可接受。 使用了Cache以后，支持的并發(fā)數(shù)明顯增多，同樣的配置可以達(dá)到100個并發(fā)用戶。響應(yīng)時間也明顯縮短。用Cache也會通過SOC訪問，而不是直接通過緩存目錄訪問圖片。 如果分布式部署，多增加兩個SOC的情況下，對Cache的服務(wù)，響應(yīng)時間明顯縮短。例如100個用戶的響應(yīng)時間從10.67縮短為4.87秒。但網(wǎng)絡(luò)流量從9.6Mb/s變?yōu)?1.6Mb/s?？梢哉f對于100Mb/s局域網(wǎng)來說還是比較繁忙的。但有一點(diǎn)可以看出，當(dāng)SOM的機(jī)器（PS

18、DServer）CPU達(dá)到87的時候兩個擴(kuò)展soc， soc1（esri-nobody）CPU利用率達(dá)到37，soc2（xxh）達(dá)到39。擴(kuò)展SOC并沒有變得特別繁忙。我認(rèn)為是SOM機(jī)器性能是整個系統(tǒng)的瓶頸所在。我們?nèi)绻^續(xù)分析各個進(jìn)程所占的CPU和內(nèi)存，可以發(fā)現(xiàn)w3wp.exe進(jìn)程有時可以達(dá)到60％以上的CPU利用率。這個進(jìn)程是IIS產(chǎn)生的。還有g(shù)srvr.exe所占的CPU也相當(dāng)可觀。這樣我們也不難理解為什么兩個擴(kuò)展SOC CPU上不去的原因了―――難道是SOM沒有CPU時間為他們分配任務(wù)？我目前這么認(rèn)為。 在不做Cache的情況下，與ArcIMS (ArcMapServer)的性能

19、差不多,從數(shù)據(jù)上看，后者稍微快－點(diǎn)（不到1秒）。 如果應(yīng)用使用兩個服務(wù)一個有Cache另外一個沒有Cache，我們非常驚訝得發(fā)現(xiàn)，居然比完全不用Cache還慢。比如當(dāng)有20個并發(fā)用戶的時候，前者的響應(yīng)速度為6.5秒，后者為5秒。這個有些不可思意，因?yàn)槲铱梢园?0％的內(nèi)容都做了Cache只留下10％的內(nèi)容非Cache! 好在ESRI USA已經(jīng)將此確認(rèn)為一個bug. 結(jié)論 測試注意事項(xiàng) Web Server的選擇 使用ASP .net只能選擇IIS。問題是開始我選擇XP操作系統(tǒng)做測試發(fā)現(xiàn)壓力老是上不去，而且老報(bào)一些Http拒絕錯誤。最后發(fā)現(xiàn)XP上的IIS只能有10個連接。最后

20、該為Windows2003 Server問題就解決了。 動態(tài)數(shù)據(jù)問題 最大的難題是如何讓測試程序訪問動態(tài)數(shù)據(jù)，也就是session中的數(shù)據(jù)。通過程序向Web Server發(fā)送一次請求，例如http://psdserver/beijingtest/, 從response的http headers中截獲SessionID.然后在后續(xù)的請求中都要使用同一SessionID，這樣才能保證訪問到內(nèi)容。否則，自動產(chǎn)生的SessionID是非法的，服務(wù)器無法識別。 測試結(jié)果的驗(yàn)證 首先最直觀的是看CPU的使用情況。看看手工操作和程序執(zhí)行對CPU的利用是否一樣。并發(fā)后CPU使用率是否提升并且連續(xù)。其次

21、看看ArcGIS Server日志或者測試程序Http 輸出是否正常。最后也可以看看有無大量圖片產(chǎn)生，看看圖片內(nèi)容是否符合預(yù)期。 對于CPU利用率不高問題，應(yīng)該是沒有訪問到動態(tài)數(shù)據(jù)導(dǎo)致的。也有可能是限制了服務(wù)器資源使用導(dǎo)致的，比如最大instance數(shù)量限制。 ArcGIS性能 ArcGIS Server的性能并非很差，相反對于如此功能豐富，且層次繁多的服務(wù)器產(chǎn)品，我覺得性能是比較高的。但是在部署的時候要注意幾個關(guān)鍵問題方可發(fā)揮且最佳性能。 ArcGIS Server地圖操作比ArcIMS稍微慢一點(diǎn)點(diǎn)（不做服務(wù)器Cache的情況下），但對ArcGIS Server來說，這點(diǎn)性

22、能代價換來的是Spatial, network，編輯等高級功能，和巨大的開發(fā)潛力。所以如果非要從速度上比較這兩個產(chǎn)品是比較牽強(qiáng)的。更多的比較應(yīng)該從功能，價格方面。 對于一些應(yīng)用采用雙Service方法（底圖Cache，功能圖層不做Cache），雖然實(shí)際速度測出來并不快，但是客戶端的體驗(yàn)卻是相反的，“視覺欺騙”仍然讓用戶比較享受。建議采用。 分析用戶的需求，盡量用Cache ！但不要忘記了Cache仍然要訪問SOC。 配置部署建議 CPU 基于ArcGIS Server的應(yīng)用都是服務(wù)器CPU密集型的，所以應(yīng)當(dāng)盡量采用多核心，主頻高的CPU。而且最好是多CPU的機(jī)器。 內(nèi)存

23、 服務(wù)啟動和服務(wù)運(yùn)行時，回產(chǎn)生大量的SOC進(jìn)程，每個進(jìn)程都要消耗較多的內(nèi)存，所以服務(wù)器內(nèi)存應(yīng)該不小于8個G。并且采用結(jié)構(gòu)先進(jìn)的內(nèi)存，以提高速度。 數(shù)據(jù)庫服務(wù)器也需要大量內(nèi)存。 網(wǎng)絡(luò) 通過測試我們發(fā)現(xiàn)對網(wǎng)絡(luò)使用還是比較大的，所以網(wǎng)絡(luò)結(jié)構(gòu)，網(wǎng)絡(luò)帶寬，網(wǎng)絡(luò)的穩(wěn)定性都有可能成為性能的瓶頸。 部署 在部署上，我們強(qiáng)烈建議將WEB SERVER 與 SOM,SOC 分開部署，最起碼要把SOC與WebServer分開部署。減少資源競爭的情況。 測試中我們發(fā)現(xiàn)很多的gsrvr.exe進(jìn)程，占用大量CPU和內(nèi)存。應(yīng)該是每一個SOC都會與ArcSDE產(chǎn)生一個該進(jìn)程。所以這里我們強(qiáng)烈推薦使用Direct connection。 最后，我們驗(yàn)證了高性能的部署模式如下：