在一台机器上安装ArcGIS 10.1 for Server后，它还无法立即工作，必须将其加入site（的cluster）之中才行。首次登录manager时，也会询问创建新的site还是加入已有的site；如果已经加入site，登录manager则会显示该site的管理目录。那么机器自身是如何判断出自己是否已经加入site了呢？ 　　依据就在于Program FilesArcGISServerframeworketc目录下的两个xml文件，config-store-connection.xml和machine-config.xml。加入site时会在本机创建这两个文件，退出site时会删除之。前者记录site的公用信息，后者记录本机在site中的信息，具体内容大家可以自己查看。 　　登录manager时会读取这两个文件，如果找不到，则认为自己没有加入site，会询问创建新site还是加入已有site；如果有这两个文件，会首先访问site的config-store目录验证其内容，合法的情况下就打开site管理目录。 如果在一台机器关机时，从site中将其删除，开机后会根据config-store-connection.xml内容去site的config-store目录中验证，发现自己已经被从site中移除后，会自己删除本机的这两个xml文件。 　　此外，如果你的机器已经加入了site A，但现在需要临时加入site B去做一些工作，就不用在admin api去删除site A了，只需将上述两个xml文件先转移到别的地方，然后登录manager，选择加入site B即可；之前site A的config-store内容可以保留，以便将先前挪走的两个xml文件复原后（需要重启ArcGIS Server服务），登录manager即可直接返回site A。

　　ArcGIS 10.1 for Server的安装目录中，都会内置一个tomcat（Program FilesArcGISServerframeworkruntimetomcat），无需单独的Web Server即可发布各种GIS服务（对于熟悉.NET的朋友来说，更省去单独安装和配置IIS的步骤）；AGS应用程序的端口号也由之前版本的80（ArcGIS Server for .NET）和8099/8399（ArcGIS Server for Java）统一到了6080上，比如http://localhost:6080/arcgis/rest/services和http://localhost:6080/arcgis/manager等。但对于内置的这个tomcat，我们并不能进行过多的操作，如果需要部署Web应用或通过别的端口来访问ArcGIS for Server的服务，这时就需要用到新的组件：Web Adaptor了。 　　Web Adaptor实际上是安装在Web Server机器上的一个Web应用程序，负责将Web Server接收到的GIS请求转发到ArcGIS Server site内的GIS Server机器上去。通过Adaptor这个桥梁，我们就能使ArcGIS for Server利用到企业级Web Server的诸多优势。根据安装帮助中的解释，安装Web Adaptor后主要有以下好处： 将单独的企业级Web Server集成到ArcGIS for Server的部署架构中来。可以将利用ArcGIS for Server服务的Web应用部署到Web Server上去；可以为site内所有的GIS Server提供不含有6080端口及arcgis等字样的统一访问入口点； 可阻止最终用户通过Web Adaptor的访问地址连接到ArcGIS for Server的相关管理程序。比如用户如果得知了类似6080端口的GIS服务访问地址，就可通过固定的url地址访问到Manger，Admin api等涉及到整个站点操作的内置应用。而Web Adaptor给我们提供了选项，可禁止用户通过Web Adaptor暴露出的GIS服务地址访问到这些管理应用。 　　此外，相对于site内的多台GIS Server机器，Web Adaptor还可以再次（除了Web Server集群外）起到负载均衡的作用，这在大并发量的情况下会比较有效。假设一个site内有n台GIS Server，它们所能处理的最大并发请求是1w个；根据ArcGIS for Server中p2p的实时通信架构，当我们将1w个并发请求发送到任一GIS Server的tomcat上时，GIS Server之间会自动以轮询（默认设置）的方式处理这些请求，GIS Server们完全可以及时响应；但1w个Web请求会首先使接收请求的这个tomcat过载，产生瓶颈。如果有了Web Adaptor，当这1w个请求到达Web Server（集群）时，Adaptor会将这些请求轮询发送到每个可用的GIS Server去，这样每个tomcat就只需支持1w/n个并发即可，可最大限度利用硬件资源。 　　以IIS中的Web Adaptor为例（经过Java高手验证WebLogic和WebSphere的Adaptor工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpubwwwrootarcgisWeb.config文件得知，IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll（在GAC目录中）里。这个dll里首先找到两个类：　　一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。 　　此外，最重要的是一个叫AGSHandler的类，它实现了IHttpHandler接口： 　　发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的，而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引： … Continue reading ArcGIS 10.1 for Server中Web Adaptor的工作原理 »

　　两年前我写过一篇关于ArcGIS地图切图/缓存原理的文章，《ArcGIS Server的切图原理深入》，里面以tiling scheme为主，讲了缓存图片的存储结构以及相关坐标的计算。那时还是ArcGIS 9.3版本，现在ArcGIS 10已经推出快一年多了，地图缓存/切图方面有了很大改进，比如增加了compact缓存格式，增加了import/export map server cache工具，增加了mixed图片模式等。这次就在上篇文章的基础上，以ArcGIS 10为例，看看其中地图切图/缓存制作的工作机制。　　注：本文旨在深入了解ArcGIS目前切图（即制作地图服务的缓存）的机制，以帮助工作中有需要的朋友们提高工作效率，因为切图，尤其是大比例尺，耗时耗资源，实在是一件伤不起的工作。这里已经假设你知道了如何为缓存地图服务配置地图，如何检查发布地图服务的地图文档的性能，开始动手前务必进行小范围、全比例尺切图试验等等注意事项，如否，请查阅相关资料。 supertile和bundle 　　要深入了解ArcGIS在切图时的工作机制，有两个概念必须明白，就是supertile和bundle。　　假设一个tile（切片）的大小是256*256，在切图时如果按照这个大小直接exportmap，开启了动态标注的地图服务上线图层和面图层就会有很多重复的标注。因为exportmap时，每个tile都会包含一个要素的标注，如果一个要素横跨了多个tile（这在大比例尺下基本是肯定的），那么这些tile上就会出现相同的标注，exportmap时并不知道相邻的tile上已经有了该要素的标注。 　　为了解决这个问题，ArcGIS在切图时引入了supertile的概念，开启抗锯齿时supertile大小为2048*2048，反之为4096*4096。真正切图时会首先exportmap出一个supertile，然后将它们分割成指定大小的tile。对于每个要素，每个supertile中只包含一次标注，这样保证一个superfile大小的范围内不会出现重复标注。事实上在绘制supertile时，会尽可能多地包含周围的标注，所以在每个supertile的边界周围仍会有重复标注。解决重复标注的根本办法就是使用annotation，而不是label。　　ArcGIS 10中推出了新的compact缓存格式，将原来离散的每个tile图片（exploded格式），保存成连续的二进制文件（.bundle），每个.bundle文件最多可存储128*128个tile。相比以前成千上万的tile文件，这样做有明显的好处：易于缓存迁移，减少占用磁盘空间，减少硬盘i/o等，esri在任何时候都推荐使用compact格式来创建缓存，除非你需要自己读取每个tile（技术上来说这点可以不成立）。ArcGIS 10在切图时，也采用了bundle的概念：对于每一级比例尺，首先从tiling scheme origin开始，将切图范围分成若干个bundle，每个bundle覆盖的范围是128*128个tile大小。比如在1:4096比例尺时，如果tile大小是256*256，DPI为96，那么每个bundle范围的大小是：((4096*2.54/96)/100/1000*256*128)^2=1261.086平方千米。之后，有且仅有（这么做是为了避免多个进程同时读写一个磁盘文件）一个服务实例/一个arcsoc.exe进程（如果是high isolated）来负责此bundle范围的切图，先输出supertile，然后再切成tile。即使选择了exploded缓存格式，ArcGIS 10中也会采用这种机制来切图。 　　9.3.1及以前版本中，每个服务实例工作的单位是supertile。即一个arcsoc.exe负责生成一个supertile，然后切成tile，再继续生成下一个supertile……相比supertile这种处理单位来说，采用bundle作为处理单位的ArcGIS 10中的服务实例可以将更多精力投入到连续切图中去，而不是频繁切换自己负责的范围。在大比例尺切图中，这种新机制能很大程度上减少切图时间；但在小比例尺切图中，这种新机制有可能反而增加切图时间。因为小比例尺时可能全图范围只有不到一个bundle范围大小，这样只会有一个服务实例来切图，其他实例都处于空闲状态，而9.3.1及以前版本中，所有服务实例都会“蜂拥而上”。 网格切图和按featureclass范围切图 　　有过大比例尺范围切图经验的朋友肯定会知道，一般切图策略是：小比例尺全图直接切，较小比例尺可能按照某个featureclass范围来切，而大比例尺一般是按照包含网格（grid）的featureclass范围来切。以我国全范围切图为例，小比例尺时全图切没有问题，大比例尺时如果仍然全图范围（包络矩形）切的话，会将周边其他的国家也包含进来，这并不需要的额外工作量在大比例尺时会是一场噩梦。 　　而之所以不仅要按指定featureclass范围切图，而且featureclass里要包含网格的原因在于，便于细化和跟踪切图进度。切图工具会给你指定的featureclass创建一个新的Cached字段，将已经切好的feature标记为YES，以便在选择Recreate Empty Cache时避免重复切图，从而可以将切图工作分为多次来进行，或者以便在切图失败后排查原因，继续切图工作。　　在指定featureclass范围切图时，是顺序处理该featureclass中的所有feature的。所有的服务实例会首先集体处理一个feature范围，切出该feature范围内所有要求的比例尺级别的结果。此时ArcGIS Server会重启该服务。然后所有服务实例再去切下一个feature范围……所以与每个feature边界相交的supertile可能会被创建两次或多次（多个feature的相交处），这也是为什么在使用featureclass切图前，需要分别对它进行Generalize，Aggregate和Dissolve的原因。 　　结合之前bundle的机制我们知道，如果一个feature范围恰好只包含一个bundle，那么就杯具了，因为对该feature切图时，只会有一个服务实例进行工作（一个bundle同时由且仅由一个服务实例处理），其他服务实例全部处于空闲状态。因此，比较理想的情况是，每个feature至少包含比服务实例数更多的bundle时，才能充分利用硬件资源来对其切图。　　这就会引出一个问题，就是如何来确定某个比例尺下一个bundle的大小，从而生成这样的featureclass呢？ArcGIS 10中，给我们提供了一个新的GP工具Map Server Cache Tiling Scheme To Polygons，利用它，我们可以针对某个地图服务，生成每个需要切图比例尺下所有的supertile，进而得到以每个supertile为一个feature的featureclass。以全国地图为例，在1:288,895比例尺（ArcGIS Online Tiling Scheme的第12级）下生成的supertile是这样的： 　　我们需要的是某个比例尺下bundle的范围，如何根据supertile来确定bundle的大小呢？在N级比例尺时，一个supertile是16*16个tile，第N+1级比例尺时，该supertile会覆盖32*32个tile，第N+2级比例尺时，覆盖64*64个tile，第N+3级比例尺时，这个第N级的supertile会覆盖128*128个tile，眼熟吧，这正是一个bundle的大小。由于supertile和bundle都是从tiling scheme origin往右下角算起的，因此第N级一个supertile的范围正是第N+3级一个bundle的范围。由此如果我们要生成第15级的bundle网格，只需要用Map Server Cache Tiling Scheme To Polygons工具生成第12级supertile的网格即可，如上图。　　以此为例，我们来说明如何有效进行大比例尺切图的问题。假设我们需要对1:36,111（ArcGIS Online Tiling Scheme的第15级）这个比例尺进行切图，我们首先生成该范围的bundle网格，恰好是第12级的supertile网格，如上图。为了简便起见，我们只取其中8个feature来做说明，地图服务的最大实例数是4个（机器是单cpu，4核）。如果每个feature恰好是一个bundle，那么一个feature只能被一个arcsoc.exe处理，而其他3个服务实例均处在空闲状态(占用内存最少的那个arcsoc.exe是用来清空工作目录的，与具体服务无关)： 　　而我们对这个featureclass做一个处理，将4个feature（恰好是一个bundle）合并成一个feature（bundle cluster），这样每个feature就恰好包含了4个bundle，如此我们所开启的4个服务实例就可全速工作了，发挥了机器的最大性能： 　　ps：Map Server Cache Tiling Scheme To Polygons工具生成的supertile是从tiling scheme origin开始计算的，而不是地图服务的fullextent左上角，因此利用它生成的supertile合并出来的bundle是最合理的，恰好与理想的bundle分界处一致。因此在大比例尺下利用featureclass切图时，应当利用Map Server Cache Tiling Scheme To … Continue reading ArcGIS Server 10中的切图/缓存机制深入 »