ArcGIS Server 性能测试报告

ArcGIS Server 性能测试方法及结果报告（仅限内部参考）测试人员许晓辉文档测试目标初步了解ArcGIS Server的性能，探索理想的ArcGIS Server部署方法。比较ArcGIS Server与ArcIMS的响应速度。力求用实用的方法，获得第一手数据，为ArcGIS Server的推广提供可参考得依据。测试环境参与测试的有4台微机：机器名硬件配置相关软件PSDServerIntel Core2 CPU 双核2.4GHZ ， 3.5G memoryWindows 2003 Server, ARCIS Server 9.2 SP3, ArcSDE 9.2 SP3, Oracle10g，ArcGIS Server 9.2 not net ADF SP3, VS2005.Esri-nobodyIntel Core2 CPU 双核 1.83GHz, 2G memeoryWindows XP sp2, ArcGIS Server 9.2 SP2xxhIntel CPU 1.66GHz ,双核，2G memoryWindows XP sp2, ArcGIS Server 9.2 SP2Esri-test3AMD Opteron (tm) Processor 144, 2.4GHZ, 2G memoryMicrosoft Application Center Test (MS ACT) 1.0测试方法及工具简介测试数据源地图文件beijingtest.mxd，按照制图要求，有渲染，有最大最小比例以及较多的标注，但标注不使用特殊效果，以减少服务器负担。地图数来源于PSDServer上的ArcSDE的北京数据, 数据比较多的图层有道路图层（25343条记录，主要单位（14500条记录）和居民区图层（约50万条记录）。将此地图发布到为ArcGIS Server的service，名为beijingtest, 并做了10级cache.地图文件Road.mxd, 包含一层数据，即PSDServer上ArcSDE中的北京道路图层，发布为ArcGIS Server的Service，名为Road, 不作cache.后面测试都是基于这两个服务展开。测试工具传统的网站（如ArcIMS HTML Viewer）都是无状态的，即每次Http请求之间没有状态要传递，那么用Load runner等工具可以录制测试脚本，进行测试。但ArcGIS 的 ADF是有状态的，状态保存在Session里面，现有的录制软件无法录制Session中的状态。HTML服务器客户端HTTPHTTPSession.Net ADFSessionIDSessionID所以只能通过遍程序来实现动态SessionID的获取和传递。我们选择Microsoft Application Center Test 1.0作为测试软件。通过fiddler2.0来截取原始的Http请求，转换后，在MS ACT中调试运行。通过调试，在ACT中将一些无关请求去掉，例如开始页中一些无用却耗时的请求，力求使得测试贴近实际使用情况。测试脚本地图操作：起始页，放大X2 ，漫游X 2，全图。共6个操作Think time设置为4到8秒的一个随机数，大约为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去掉。并将其初始最小instance设置为20。结果：30个并发用户CPU达到了97。所以就测试到30个用户。客户端响应情况：用户数迭代时间地图操作响应速度103002.196721311203004.9890109893030010.48351648服务器的资源使用情况：用户数服务器CPU服务器网络内存10631800006320902620006330972530006420个并发时服务器的CPU内存：20个并发时服务器的各个进程使用CPU和内存情况：ArcGIS Server 使用Cache 情况下的性能：说明：测试Beijingtest服务，最小进程数设置为20。启用cache。结果：响应明显加快，数据如下：客户端响应情况：用户数迭代时间地图操作响应速度101801.317073171201801.5301801.894736842403001.547169811503002.333333333603004.309278351703005.98630137803007.4228187929030010.3043478310030010.66666667服务器的资源使用情况：用户数服务器CPU服务器网络内存101718800057204050000057.7305072300058.940661070000605073113000059608111700006070851280000608086110000060.290881110000611008912000006180个用户的情况下CPU内存使用情况：80个用户的情况下各个进程使用cpu内存的情况：ArcGIS Server在多个服务的情况下（底图是Cache的）的性能：说明：用带cache的beijingtest服务作为底图，以Road服务作为浮动图层。这样可以模拟那些需要编辑等高级功能的图层。结果：客户端响应情况：用户数迭代时间地图操作响应速度103002.064516203006.53030010.66667服务器的资源使用情况：用户数服务器CPU服务器网络(Byte/s)内存(%)10603800005920905000006030955800006030个用户的时候服务器CPU内存使用情况：扩展ArcGIS Server SOC对性能的影响：说明：将机器xxh和 Esri-nobody作为PSDServer的SOC，同事PSDServer上保留SOC但最多限制25个instance。将Beijingtest初始的instance数量设置为30。这样，PSDServer就做为WebServer, ArcSDE Server, 数据库服务器，SOM存在。结果：服务器的资源使用情况：用户数地图操作响应速度 (典型部署方式)地图操作响应速度 (分布式部署)502.331.18604.311.65705.992.22807.422.559010.3410010.674.87服务器的资源使用情况：用户数典型式分布式CPU%5073som+soc:67,soc1:25,soc2:286081som+soc:76,soc1:30,soc2:357085som+soc:76,soc1:34,soc2:408086som+soc:86,soc1:35,soc2:419088som+soc:84,soc1:35,soc2:3810089som+soc:87,soc1:37,soc2:39网络 Mb/s509.0415.68609.3619.27010.2421.6808.822.4908.88201009.621.6ArcGIS Server与ArcIMS的性能对比：说明：使用同样的数据源和地图文档beijingtest.mxd。ArcIMS使用ArcMapServer，并用ArcIMS Web Manager for Microsoft dot Net Framework发布一个应用。采用和ArcGIS Server同样的方法测试。ArcIMS版本为9.2 SP3。ArcIMS配置10个instances.ArcGIS Server 初始配置20个instance. 虽然instance数量不同，但根据经验不会影响结果。因为最终限制结果的是系统资源而不是instance的数量。结果：服务器的资源使用情况：用户数地图操作响应速度服务器CPU服务器网络服务器内存ArcIMS101.936507937556100050204879250052308.285714286979500050ArcGIS Server (Cache)101.31707317117%18800057201.54050000057.7301.8947368425072300058.9401.54716981166107000060502.33333333373113000059604.30927835181117000060705.9863013785128000060807.42281879286110000060.29010.304347838811100006110010.6666666789120000061ArcGIS Server (No Cache)102.1967213116318000063204.98901098990262000633010.483516489725300064结果分析不用Cache，用Cache做底图再用一个非cache的服务做浮动图层，或者用ArcIMS ArcMapServer，这三种情况下最多30个用户就可以让PSDServer的CPU达到90以上，这时如果再加更多的用户只能导致响应时间不可接受。使用了Cache以后，支持的并发数明显增多，同样的配置可以达到100个并发用户。响应时间也明显缩短。用Cache也会通过SOC访问，而不是直接通过缓存目录访问图片。如果分布式部署，多增加两个SOC的情况下，对Cache的服务，响应时间明显缩短。例如100个用户的响应时间从10.67缩短为4.87秒。但网络流量从9.6Mb/s变为21.6Mb/s。可以说对于100Mb/s局域网来说还是比较繁忙的。但有一点可以看出，当SOM的机器（PSDServer）CPU达到87的时候两个扩展soc， soc1（esri-nobody）CPU利用率达到37，soc2（xxh）达到39。扩展SOC并没有变得特别繁忙。我认为是SOM机器性能是整个系统的瓶颈所在。我们如果继续分析各个进程所占的CPU和内存，可以发现w3wp.exe进程有时可以达到60以上的CPU利用率。这个进程是IIS产生的。还有gsrvr.exe所占的CPU也相当可观。这样我们也不难理解为什么两个扩展SOC CPU上不去的原因了难道是SOM没有CPU时间为他们分配任务？我目前这么认为。在不做Cache的情况下，与ArcIMS (ArcMapServer)的性能差不多,从数据上看，后者稍微快点（不到1秒）。如果应用使用两个服务一个有Cache另外一个没有Cache，我们非常惊讶得发现，居然比完全不用Cache还慢。比如当有20个并发用户的时候，前者的响应速度为6.5秒，后者为5秒。这个有些不可思意，因为我可以把90的内容都做了Cache只留下10的内容非Cache!好在ESRI USA已经将此确认为一个bug.结论测试注意事项Web Server的选择使用ASP .net只能选择IIS。问题是开始我选择XP操作系统做测试发现压力老是上不去，而且老报一些Http拒绝错误。最后发现XP上的IIS只能有10个连接。最后该为Windows2003 Server问题就解决了。动态数据问题最大的难题是如何让测试程序访问动态数据，也就是session中的数据。通过程序向Web Server发送一次请求，例如http:/psdserver/beijingtest/, 从response的http headers中截获SessionID.然后在后续的请求中都要使用同一SessionID，这样才能保证访问到内容。否则，自动产生的SessionID是非法的，服务器无法识别。测试结果的验证首先最直观的是看CPU的使用情况。看看手工操作和程序执行对CPU的利用是否一样。并发后CPU使用率是否提升并且连续。其次看看ArcGIS Server日志或者测试程序Http 输出是否正常。最后也可以看看有无大量图片产生，看看图片内容是否符合预期。对于CPU利用率不高问题，应该是没有访问到动态数据导致的。也有可能是限制了服务器资源使用导致的，比如最大instance数量限制。 ArcGIS性能ArcGIS Server的性能并非很差，相反对于如此功能丰富，且层次繁多的服务器产品，我觉得性能是比较高的。但是在部署的时候要注意几个关键问题方可发挥且最佳性能。ArcGIS Server地图操作比ArcIMS稍微慢一点点（不做服务器Cache的情况下），但对ArcGIS Server来说，这点性能代价换来的是Spatial, network，编辑等高级功能，和巨大的开发潜力。所以如果非要从速度上比较这两个产品是比较牵强的。更多的比较应该从功能，价格方面。对于一些应用采用双Service方法（底图Cache，功能图层不做Cache），虽然实际速度测出来并不快，但是客户端的体验却是相反的，“视觉欺骗”仍然让用户比较享受。建议采用。分析用户的需求，尽量用Cache ！但不要忘记了Cache仍然要访问SOC。配置部署建议CPU基于ArcGIS Server的应用都是服务器CPU密集型的，所以应当尽量采用多核心，主频高的CPU。而且最好是多CPU的机器。内存服务启动和服务运行时，回产生大量的SOC进程，每个进程都要消耗较多的内存，所以服务器内存应该不小于8个G。并且采用结构先进的内存，以提高速度。数据库服务器也需要大量内存。网络通过测试我们发现对网络使用还是比较大的，所以网络结构，网络带宽，网络的稳定性都有可能成为性能的瓶颈。部署在部署上，我们强烈建议将WEB SERVER 与 SOM,SOC 分开部署，最起码要把SOC与WebServer分开部署。减少资源竞争的情况。测试中我们发现很多的gsrvr.exe进程，占用大量CPU和内存。应该是每一个SOC都会与ArcSDE产生一个该进程。所以这里我们强烈推荐使用Direct connection。最后，我们验证了高性能的部署模式如下：