ArcGIS Server 性能測試報告

《ArcGIS Server 性能測試報告》由會員分享，可在線閱讀，更多相關《ArcGIS Server 性能測試報告（12頁珍藏版）》請在裝配圖網上搜索。

1、 ArcGIS Server 性能測試方法及結果報告 （僅限內部參考） 測試人員 許曉輝 文檔 測試目標 初步了解ArcGIS Server的性能，探索理想的ArcGIS Server部署方法。比較ArcGIS Server與ArcIMS的響應速度。力求用實用的方法，獲得第一手數據，為ArcGIS Server的推廣提供可參考得依據。 測試環(huán)境 參與測試的有4臺微機： 機器名 硬件配置 相關軟件 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 測試方法及工具簡介 測試數據源 地圖文件beijingtest.mxd，按照制圖要求，有渲染，有最大最小比例以及較多的標注，但標注不使用特殊效果，以減少服務器負擔。地圖數來源于PSDServer上的ArcSDE的北京數據, 數據比較多的圖層有道路圖層（25343條記錄，主要單位（14500條記錄）和居民區(qū)圖層（約50萬條記錄）。 將此地圖發(fā)布到為ArcGIS Server的service，名為beijingtest, 并做了10級cache.

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

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

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

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

8、 ArcGIS Server 使用Cache 情況下的性能： 說明：測試Beijingtest服務，最小進程數設置為20。啟用cache。 結果：響應明顯加快，數據如下： 客戶端響應情況： 用戶數 迭代時間 地圖操作響應速度 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 服務器的資源使用情況： 用戶數 服務器CPU 服務器網絡 內存 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＆內存使用情況： 80個用戶的情況下各個進程使用cpu＆內存的情況： ArcGIS Server在多個服務的情況下（底圖是Cache的）的性能： 說明：用帶cache的beijingtest服務作為底圖，以Road服務作為浮動圖層。這樣可以模擬那些需要編輯等高級功能的圖層。 結果： 客戶端響應情況： 用戶數 迭代時間 地圖操作響應速度 10 300 2.064516 20 300 6.5 30 300 10.66667 服務器的資源使用情況： 用戶數 服務器CPU 服務器網絡(Byte/s) 內存(

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

12、使用情況： 用戶數 地圖操作響應速度 (典型部署方式) 地圖操作響應速度 (分布式部署) 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 服務器的資源使用情況： 　 用戶數 典型式 分布式 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 網絡 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的性能對比： 說明：使用同樣的數據源和地圖文檔beijingtest.mxd。ArcIMS使用ArcMapServer，并用ArcIM

14、S Web Manager for Microsoft dot Net Framework發(fā)布一個應用。采用和ArcGIS Server同樣的方法測試。ArcIMS版本為9.2 SP3。ArcIMS配置10個instances. ArcGIS Server 初始配置20個instance. 雖然instance數量不同，但根據經驗不會影響結果。因為最終限制結果的是系統(tǒng)資源而不是instance的數量。 結果： 服務器的資源使用情況： 　 用戶數 地圖操作響應速度 服務器CPU 服務器網絡 服務器內存 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 結果分析 不用Cache，用Cache做底圖再用一個非cache的服務做浮動圖層，或者用ArcIMS A

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

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

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

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

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

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

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