企业级 GIS 性能和可伸缩性（一）——基础设施

最新推荐文章于 2022-01-12 08:30:00 发布

积思园

最新推荐文章于 2022-01-12 08:30:00 发布

阅读量3.3k

点赞数

分类专栏： ArcGIS Server ArcSDE Oracle 性能优化

ArcSDE 同时被 3 个专栏收录

193 篇文章 13 订阅

订阅专栏

Oracle

106 篇文章 0 订阅

订阅专栏

性能优化

54 篇文章 2 订阅

订阅专栏

性能是计算机系统工作速度的度量值。可伸缩性则是一种在不带来负面影响的前提下增加大小和复杂性的能力。这两者任一方面出现问题都可能导致企业级系统的运作效率低下，并引发关键业务组件的潜在性常规故障。对环境的测试、监控和调整一定程度上可确保最佳性能的获取从而提高用户满意度。

基础设施性能注意事项

在实现企业级 GIS 的过程中选择正确的硬件及其后续的配置会对解决方案的性能和可伸缩性产生显著影响。有关特定基础设施组件的性能和可伸缩性等详细信息，请参阅右侧的链接。

性能因素

技术架构中通常存在以下几个需要注意的性能指示器，如下所示：

技术架构的常见性能因素

类别	影响*	注意事项
CPU	高值	有关 CPU 速度比较的信息，请参阅 SPEC.org。
WAN 上行速率	高值	确保充足的带宽非常重要。通常，ArcGIS Server 地图的网络要求大约为每个事务 2 至 8 Mb。对于大容量请求，T1 (1.544 Mbps) WAN 上行速率经常不够用。
应用程序虚拟化	高值	应用程序级别的虚拟化常用于保障终端用户性能下降最小的情况下对各远程用户的数据集进行集中化。
硬件虚拟化	低值	应用程序级别的虚拟化常用于保障终端用户性能下降最小的情况下对各远程用户的数据集进行集中化。虚拟硬件解决方案可在系统 I/O 增加时产生显著的影响。
LAN 网络	中度	注意组件之间的内部振动。通常，100Mbps LAN 带宽对于客户端已足够，1Gbps 用于服务器网络连接。
磁盘速度	中度	通常，ArcGIS 系统受 CPU 限制。然而，需要有大量请求写入单个输出或作业目录的系统可能会受到 I/O 限制。因此，您可能需要使用更快的磁盘、RAM 磁盘或固态磁盘。
共享存储	低值	NAS 的影响及关于网络吞吐量的注意事项。
负载平衡器	中度	负载平衡允许轻松扩展 Web 层。
Web 应用程序服务器	中度	不同的 Web 应用程序服务器平台可提供附加的管理、监视和可伸缩性选项。
硬件虚拟化	中度	虚拟硬件解决方案可在系统 I/O 增加时产生显著的影响。
操作系统	中度	通常，软件组件在其本地的构建环境中运行得更快。
数据源	中度	关系数据库和基于文件系统的存储属性差异很大。

*其中“高”表示对总体性能有较大影响（正面或负面）。

性能因素

典型的主要因素可包括性能、可伸缩性和可用性。下表提供了许多常见数据源在各个类别中的常规等级。

数据源的性能因素

数据源	性能	可伸缩性	高可用性	注意事项
文件地理数据库	高	低	低	多复本
ArcSDE/SQLServer Esri 二进制	高	高	高	集群式
ArcSDE/SQLServer 几何	高	高	高	集群式
ArcSDE/Oracle esri ST_Geometry	高	高	高	RAC
ArcSDE/Oracle SDO	高	高	高	RAC
ArcSDE/Postgres	高	高	高
ArcSDE/DB2	高	高	高
ArcSDE/Informix	高	高	高
Shapefile	高	低	低	共享数据
个人地理数据库	高	低	低	相对较低的大小限制

调整和优化

在优化数据源时应考虑以下主题：

存储硬件
数据格式
数据位置
维护例程
创建属性索引
配置 DBMS
更新统计数据
重新构建索引

可伸缩性策略

可伸缩性通常涉及横向和纵向扩展下列组件：

部署多个文件数据源，例如多台计算机上的文件地理数据库
DBMS 集群解决方案，例如 Oracle RAC
纵向扩展数据服务器（选择更大的服务器或添加更多资源）

性能特征

随着环境中数据集的大小和并发用户负载的增加，对于磁盘子系统的选择也变得越来越重要。本节简单介绍了与 ArcGIS 实施的性能和可伸缩性相关的几种不同的存储机制。

NAS（网络附加存储）

共享存储通常是企业内部在不同服务器间共享数据的一种经济有效的方法。它也是另一种在各种服务器产品之间交换数据的方法，但当数据吞吐量可能超过连接应用程序层和存储的网络接口速度时，这种方法就不适用了。ArcGIS Image Server 和 ArcGIS Server 2D 缓存对数据吞吐量的要求很高，实际上可能超过单个千兆比特连接的可用带宽。有些 NAS 设备可提供多个接口以便产生更多的带宽，甚至比千兆比特快很多倍的网络连接。不过，这需要购买其他的配套基础设施。

NAS 的一个优势在于它能够使远程用户通过使用网络协议（如 CIFS 和 NFS）同步访问一个共享驱动器。

DAS（直接连接存储）

术语“直接连接存储”指的是可直接连接到主机系统的存储设备。最简单的例子就是服务器的内部硬盘驱动器。到目前为止，DAS 仍然是计算机系统存储数据最常用的方法，并且 DAS 技术通常没有 SAN 技术那么复杂。可通过向服务器内部（或向某个空驱动器托架）添加磁盘或添加外部磁盘柜来实现扩展。

实际上，通过启用和正确配置网络协议（如 CIFS 或 NFS），直接连接存储服务器便可作为 NAS 服务器。

SAN（存储区域网络）

SAN 指的是一种向远程计算机提供存储的方式，采用这种方式时磁盘（也称为逻辑单元或 LUN）在操作系统中显示为本地驱动器。这使远程系统能够以有利于其任务处理的方式来格式化和准备 SAN 磁盘。SAN 和远程计算机之间的连接媒介可以是提供高带宽的“光纤通道”。

与 NAS 不同，当仅使用 SAN 技术时，只有一台远程主机可以访问并控制 LUN。与其他存储系统相比，SAN 更加复杂且费用更高，但是 SAN 的存储能力非常强大。

iSCSI 协议

iSCSI 是 SAN 使用的一种规范，它可以使存储设备在 IP 网络中实现数据传递。将 SCSI I/O 协议映射为 TCP 协议即意味着在传统网络（LAN 或 WAN）中提供“块级别 I/O”存储。这也使得 SAN 不需要更改其物理连接就可以方便的调节其存储能力。除此之外，NAS 和 SAN 设备可以使用相同的环境基础设施来共享数据。

磁盘存储类型

属性	DAS	SAN	NAS
性能	中	高	中，受网络带宽限制
存储和处理器之间的连通性	单台存储设备连接到单台处理器（主机）上	每个 LUN 一台处理器（主机），但单台处理器可使用多个 LUN。	每个共享驱动器多台主机
I/O 请求（访问）	块级别	块级别	文件级别（网络协议）
I/O 协议	SCSI、FC	iSCSI、FC (HBA)	CIFS、NFS、HTTP
容量	不需要共享信息的小型企业或部门	企业级公司	中型/企业级公司（数据中心）
可伸缩性	中等（弱于 SAN）	高	中等（弱于 SAN）
总拥有成本	原始成本比较低，但由于缺乏适当的共享，成本会越来越高。	实施所需的原始成本高于 DAS/NAS 的原始成本。	实施所需的原始成本高于 DAS 的原始成本。
特点	不易于与其他处理器共享未使用的容量。比 SAN 更易于安装和管理。 RAID/Hot 热插拔驱动器和组件。易扩展性	多种多样的故障转移和容错特性。高速“光纤通道”通信。单点控制将多个磁盘和磁带看做一个由单点控制的共享池进行管理 SAN 的规划设计时间更长。可对所选数据包进行快照备份。	高带宽聚类和数据复制/镜像。比 SAN 更易于安装和管理。 RAID/Hot 热插拔驱动器和组件。可对大多数设备进行快照备份。易扩展性
预算考虑	比 SAN 更简单、便宜	部署和管理费用高	比 SAN 更简单、便宜
管理开销	低	高	中
跨平台操作支持（如 Linux、Windows 和 Mac）	每个服务器将在各自的操作平台中运行（没有跨平台的公用存储）	取决于专有 HBA 驱动器	由于可同时使用各种不同的网络协议，因此跨平台支持适用于所有操作系统（异构操作系统）。
用法	成像应用程序、文件服务器、电子邮件服务器、网络服务器。	并行数据库、高带宽视频流、影像和事务处理	成像应用程序、文件服务器、电子邮件服务器、网络服务器。

磁盘存储技术和驱动器接口

属性	SAS	SATA	固态	RAM 磁盘
性能	高	中	极高	极高
支持的磁盘速度	15K、10K、7.2K RPM	7.2K、5.4K RPM	无移动部件（无 PRM）	无移动部件（无 PRM）
容量	高，但具体容量大小取决于磁盘的速度	高	低	极低
功耗	功耗高于同等的 SATA	由于 RPM 速度较低，因此功耗低于 SAS	功耗低于磁机械驱动器（如 SAS 和 SATA）	基于系统内存消耗
成本	成本高于 SATA	每 GB 的成本最低	成本高于 SAS 和 SATA	每 GB 的成本最高

操作系统	注意事项
Windows 2003、2008	选择 64 位操作系统可提供更大的内存容量。这有助于 IIS 的扩展。
Windows XP、Windows Vista、Windows 7	主要用于富客户端应用程序解决方案和开发
Red Hat	COM 仿真支持将 Esri 软件中的 COM 对象用于动态数据
Suse	COM 仿真支持将 Esri 软件中的 COM 对象用于动态数据
Solaris（在 SPARC 芯片上）	COM 仿真支持将 Esri 软件中的 COM 对象用于动态数据

性能因素

Esri 所执行的虚拟化测试表明频繁的磁盘 I/O 操作（如动态制图和地图缓存），在物理计算机上的执行速度比在虚拟计算机上快。一些 CPU 处理密集的应用程序在虚拟环境中也会受到负面影响。测试表明，应用程序的性能可能因虚拟化供应商的不同而有所差异（有时效果非常明显），也可能因所执行的操作不同而不同。例如，相应于虚拟化供应商的不同，通过 REST API 对中等复杂的地图服务（40 个矢量图层及 3 个栅格图层）所执行的 ExportMapImage 操作的调用，会导致 20% 到 30% 的性能损失。需要重点强调的是，虚拟环境的次最优配置可能导致高达 60% 的性能损失。

工具

性能基准的及格分数

有关详细信息

ArcGIS Server 和虚拟化白皮书 - Esri 硬件虚拟化指导
基准：带 Citrix Presentation Server 的 ArcGIS Desktop 9.3.1
虚拟化最佳实践 - Computer Associates (CA) 的虚拟化建议

----------------------------------------------------------------------------------

From： resources.arcgis.com

Blog: http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------

网络性能因素

GIS 操作，与文档管理和视频会议企业级解决方案一起，被认为是网络中最繁忙的数据传输类型。丰富的地理数据往往导致地理信息系统的数据量十分庞大，而 GIS 分析的优势在于它能够快速检查大量数据，并将其转变成对您有用的信息（信息产品）。有很多因素都会影响 GIS 企业解决方案在网络中的性能。

性能因素

下表列出了在各种应用架构中需要考虑的影响网络负载的关键因素：

应用程序架构的网络负载因素

应用程序架构	网络负载	每次显示的兆比特数	备注
富客户端应用程序	重度	10	由于比较烦琐，所以通常建议只用于 LAN
通过 Citrix 的富客户端应用程序（图像）	中度	5	Citrix 或终端服务连接可提供强大的用户界面，同时减轻 WAN 的网络负载
通过 Citrix 的富客户端应用程序（矢量）	轻度	3	Citrix 或终端服务连接可提供强大的用户界面，同时减轻 WAN 的网络负载
Web 应用程序（动态）	中	2	与 REST API 应用程序相比，基于 ADF 的应用程序通常具有较重的网络负载
Web 应用程序（已缓存）	中度	1	与 REST API 应用程序相比，基于 ADF 的应用程序通常具有较重的网络负载
移动应用程序	轻度	0.05	仅定期发送增量更新
服务 (REST)	中度	2	基于 REST 的服务主要用于轻度负载
服务 (SOAP)	中度	3	SOAP 是较为强大的通信机制，因此在 WAN 上具有更重的足迹

调整和优化

您可以调整的影响网络负载的主要因素包括：

Internet 浏览器缓存策略 - 某些组织可能会禁用本地缓存，从而增加了网络负载
新用户的百分比 - 新增用户未在本地系统上缓存数据，从而增加了网络负载
图像大小 - 客户端显示的图像越小，所需的网络流量则越少
图像格式 - 通常对于栅格来说，JPEG 的负载最轻；对于矢量来说，PNG 的负载最轻
混合位置 - 应用程序可用于在客户端或服务器端混合图像。客户端的混合将增加客户端的网络负载（通常受到最大程度的约束），服务器端的混合将增加服务器/数据中心的网络负载。

LAN 性能

由于 GIS 应用程序在网络上传输的流量通常较大，以下是所建议的 LAN 组件的吞吐量：

客户端 - 100 兆/秒
服务器端 - 1 千兆/秒

WAN 性能

由于广域网 (WAN) 的带宽较小且延迟较高，因此还需要考虑一些其他因素。出于性能考虑，数据总量对于 WAN 上的企业 GIS 解决方案将是一个非常关键的因素。数据总量是在给定的时间范围内能够通过网络传输的数据量。该数量由带宽和延迟共同确定。带宽是网络连接中的传输速度，单位是千比特/秒。延迟是指将数据从一点传输到另一点所需花费的时间（以毫秒为单位）。这两个因素将共同确定能够在给定的时间范围内通过网络传输的数据量。这两个因素的综合结果将直接影响用户对处理事务所需时间的感受。

在评估网络连接时需要评估带宽及延迟，您会发现尽管某些类型的网络连接可以最大程度地提高带宽，但是这样可能会增加延迟。例如，与地面连接（如帧中继或拨号综合业务数字网 (ISDN)）相比，卫星连接可以提供高带宽，但延迟时间可能会更长。

减少客户端/服务器端应用程序执行的事务量可起到很大的帮助。不过，通常对于 IT 商店来说，改变客户端/服务器端应用程序的编写方式可能不切实际。Citrix 和终端服务器可对此提供帮助，因为大量事务都可通过一个慢速链接来执行。ICA 或 RDP（Citrix 和终端服务器使用的协议）在数据传输方面表现的相对较好，更适用于容易出现延迟问题的慢速链接。许多大型 Citrix 实现方法针对 Esri 产品已得到了成功的执行。实施 Citrix 解决方案的最常见原因是为了提高应用程序在具有最小带宽和/或高延迟的 WAN 连接中的性能。

一些客户已使用诸如 NetScaler 或 BranchRepeater（以前称为 WANScaler）等组件提高其吞吐量，而另一些则使用加速服务提供程序（例如 Akamai）在 Internet 上提供了大规模解决方案，该程序可通过分散的数据中心将缓存的信息从产品分布到世界各地。通常，使用这些解决方案不仅可以减轻网络负载，还可以减轻服务器负载，减少量可达 30%。个别解决方案的效率可能会有明显不同，这取决于具体的应用程序，因此请确保在假设效率提高之前执行测试和验证。

----------------------------------------------------------------------------------

Blog: http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------

负载平衡性能因素

负载平衡是一种通过将工作负载分发到两台或两台以上服务器来实现更多的冗余、更好的伸缩性或安全性的方法。“平衡”可通过软件或专用硬件执行，但都会形成跨多台计算机的负载分布。从 Web 服务器或 Web 服务的角度来看，之后客户端通过利用负载平衡器只需访问一个 URL 即可，十分便捷。然后，发送到该位置的用户请求将由负载平衡器处理，并以透明方式发送到执行实际处理过程的某一台可用的后台计算机。

负载平衡器具有许多特性，其中的某些特性具备其他特性所没有的能力与功能。以下汇总了在将负载平衡器部署到 GIS 环境时可起到重要作用的各种特质。

物理特征

软件还是硬件？基于软件的解决方案具有成本更低的优势，并且能够运行在现有服务器上。另一方面，基于硬件的解决方案可提供更多的功能，并且可拥有针对特定任务（如 SSL 卸载引擎）的内置加速器。

平衡度量

负载平衡器必须通过某种类型的指标或调度程序确定要执行的工作的展开方式。通常，这可以通过平衡算法（例如轮询、服务器负载、服务器计算能力、最少连接或随机）来实现。能够自定义此方法表明负载平衡器十分便捷。如果后端服务器不完全相同，则根据服务器计算能力调整平衡方法可提供与未超载的较慢计算机一样的平稳负载。

安全性

安全性始终是一个重要方面。负载平衡器通常会带来额外的好处，即隐藏对请求的服务起到实际作用的后台网络和服务器。从某个 URL（负载平衡器）请求地图服务的过程在实际上可能是从防火墙后面的多个不同服务器汇集信息的过程。由于仅允许通过负载平衡器进行通信，所以得益于仅有一个入口点，防火墙的安全性得到提升。

某些负载平衡器还配备有一些分析功能，可以检测拒绝服务 (DoS) 攻击并采取防护性措施。

性能

负载平衡器的后台服务器如果仅拥有最快的 CPU 将无法始终保证提供对请求的最快响应时间。通过将某些 Web 服务器的杂项事务和日常职责（如 SSL 加速）交给负载平衡器可从中获得更多的容量。此外，某些负载平衡器拥有执行 HTTP 压缩和 HTTP 缓存的能力。

HTTP 压缩可将发回到用户的某些请求的数据量变得更小，从而节省珍贵的网络带宽。这当然需要由通常对于终端用户透明的客户端浏览器进行解压缩。一旦从负载平衡器自身的“内存”检索到一同发送给后端服务器的请求，HTTP 缓存可帮助清除这些请求，这可以极大地减少请求的响应时间并提升总体吞吐量。值的注意的是，对缓存地图数据的折衷方案并不一定始终最符合现状，但是缓存到期和缓存重新生成这样的负载平衡器配置可提供一些灵活的选择。

监控和维护

分布工作负载很重要，但能够自动检测并处理后端服务器的故障和恢复是至关重要的。负载平衡器在这一方面提供多种不同的功能。尽管某些负载平衡器仅能检测服务器是否处于活动状态以及是否在网络中，但是其它负载平衡器却具有非常精细的方法，例如从预先确定的 Web 页面中检索内容。这对 GIS 环境来说十分有利。您不仅可以定期检查 HTTP 服务器是否工作正常，而且可以检查地图服务是否正在返回预期的输出。值得一提的是，应谨慎使用检查地图服务是否基于软件堆栈建立其内容可用性的功能。执行检查过于频繁可能耗尽后端服务器上的资源，进而殃及性能。如果需要进行重复验证，请尽可能使用量级最轻和/或占用空间最小的功能来分析。

与自动故障检测类似，对于维护来说，非常需要拥有能够将计算机手动标记为故障状态的功能。将服务器标记为“健康”（手动或自动均可，表示服务器可再次开始为请求提供服务）同样是一项强大的功能。

可伸缩性

可伸缩性是负载平衡器的关键优势和用处之一。这种平衡赋予它通过将请求分布到两台或多台服务器来帮助保持较短响应时间的能力。如果服务器因工作过多而发生过载，则排队启动时间和响应时间都会增加。在保持所有后端服务器都在平稳状态下执行工作的前提下，可以让更多用户加入到环境中，进而实现可伸缩性。

会话状态

某些应用程序带有“会话状态”。当涉及到状态之后，需要更加关注平衡负载。因为在默认情况下，状态贮存在应用程序服务器空间中，请求无法转到任何其他的服务器。负载平衡器可通过利用能够保持用户进入的始终是源服务器的会话状态的粘性或持续性来帮助协调解决这一问题。备选解决方案是将会话存储到数据库之类的共享资源中。当然，该数据库之后也应拥有自己的负载平衡机制。根据共享资源的大小，将会话状态复制到环境中的另外一层可使性能受到影响，这一点应考虑在内。