您的位置：首页 > 其它

企业级 GIS 性能和可伸缩性（三）——容量和测试

2014-03-07 08:58 288 查看

容量规划

容量规划、性能基准和确认测试是企业级系统实现取得成功的关键要素。本节提供了以下三方面内容：容量规划过程的相关信息、Esri 性能测试过程概述以及执行方案测试的常规指导。以下情况需要进行容量规划：设计一个新的系统
从一个解决方案迁移到另一个解决方案（例如从非 Esri GIS 迁移到 Esri GIS）
升级现有 Esri GIS 配置
业务流程和模型发生了更改，因此需要对应用程序架构进行更新
终端用户群体在数量、位置或功能方面发生了显著变化
容量规划需要从以下内容着重评估：CPU 内核的数量和速度
所需的网络带宽
内存大小
存储类型和大小
影响容量的关键因素：并发用户数
用户工作流
架构
性能调整和最佳做法的实现

性能基准和测试

性能基准和测试是容量规划过程中不可或缺的组成部分。企业级 GIS 解决方案的测试是确保项目成功的重要步骤。性能测试的目标包括：进行基准测试以证明性能的提高
正式验收测试的一部分
容量规划（调整服务器规模）
确认系统架构设计
性能测试的优点包括：了解有关应用程序性能和伸缩性的定义度量，例如响应时间、吞吐量和资源利用率
建立性能基线
发现应用程序、基础设施或数据库的潜在瓶颈
建立应用程序负载与其对基础设施的影响两者之间的关联
发现未充分利用的资源以重新进行部署
预测性能和容量要求以满足企业需要
确定
系统是否以最佳性能运行
如何管理增加的用户负载
什么组件最影响服务层级，影响程度如何
什么组件造成服务质量下降，造成的负荷多大

----------------------------------------------------------------------------------版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!From： resources.arcgis.comBlog: http://blog.csdn.net/linghe301----------------------------------------------------------------------------------
Esri 性能基准

Esri 专业服务执行一系列支持每个 Esri 核心软件版本的性能验证测试。此外，它还评估 Esri 和第三方产品。这些结果用于验证 Esri 软件的性能和可伸缩性，以及为基于 Esri 的解决方案提供容量规划的相关信息。本部分提供了对 Esri 测试过程的概述以及对性能基准的说明（可在实现方法库中找到）。

Esri 基准

Esri 专业服务在实现方法库中执行和发布典型测试结果的性能基准。这些基准有助于：确定系统规模
容量规划模型的校准和输入
最佳技术架构的选择
最佳应用程序架构的选择
在没有相应性能基准的情况下，执行有效的容量规划可能具有挑战性或无法实现。在许多情况下，不使用测试数据进行估计或使用过时的容量模型均可导致显著误差。这可导致性能下降，同时硬件和许可成本增加。性能基准提供了用于大小调整估计和用于容量规划输入的重要信息，主要包括：CPU 服务时间
网络兆比特/事务
计算机规格等级（用于不同硬件的结果外推）
最大吞吐量
给定用户负载的响应时间

所需调整

应用 Esri 基准结果时，可能需要对以下关键因素进行调整。

调整工作流相对差异

在早期规划阶段确定工作流的所有详细信息可能非常困难。但是，对于早期容量规划，可能不需要所有操作信息，但是要关注：响应时间较长且执行频繁的事务
批处理操作 - 响应时间很长的事务

调整事务大小相对差异

事务“大小”差异通常与不同的因素相关联：数据源
对于地图服务，ArcMap 文档的内容和配置（图层数、比例和符号系统）
图像压缩
地图显示尺寸
缓存服务与动态服务

调整架构差异

许多 Esri 基准都是在非分布式或工作组测试环境中执行的。此解决方案的性能和可伸缩性与分布式环境有所不同。例如，可能无法提取特定组件的资源利用率，例如，通过采用在单个服务器上执行的基准的 SOC 或数据库并应用到分布式架构。此外，CPU 核心总数可能会有所不同，该总数会对系统的整体可扩展性（以最大吞吐量 (TPH) 测量）产生影响。对于不同的工作流，可以使用各个事务的已发布 CPU 服务时间（如果可用）来对容量进行建模。

调整相对 CPU 速度差异

该差异可以作为每个核心已发布基准的规格等级 CINT 2006 基础的比率进行测量。应该注意，对于在负载相对较小的情况下运行的系统，CPU 速度（而非核心数）将会对系统性能产生很大影响。

其他支持

“Esri 专业服务”为这些技术领域提供了各种服务。请联系 Esri 专业服务。

相关链接

ArcGIS 测试方法 - Esri 2010 开发者大会演示文稿
团队系统测试工具入门 - Microsoft 测试解决方案
Fiddler - 免费 HTTP 流量检查器应用程序

----------------------------------------------------------------------------------版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!From： resources.arcgis.comBlog: http://blog.csdn.net/linghe301----------------------------------------------------------------------------------
测试应用程序

性能测试可在功能和系统等相关问题对最终用户造成影响之前，提前引导开发者确定解决方案，并能够发现瓶颈问题和/或未充分利用的资源以重新进行部署。要确保成功进行企业级实施，请执行下列测试步骤：应用程序功能性测试 - 应用程序功能性测试是成功实施 GIS 的一个关键步骤。应用程序完整、可靠、合理并能够呈现所规定的业务需求，这一点十分重要。
系统调优 - 测试通常会发现需要改进的方面（如性能低下）。在此阶段，您应当实施性能和可伸缩性最佳实践，以确保所测试的系统能够提供有效的结果。这可能包括对于地图文档、数据位置以及数据结构修改等方面的评估。
测试方案开发 - 要取得测试成功并拥有实用有效的测试结果，您必须制定综合性测试方案，要有来自领域/职能性专家的参与、用户工作流的文档说明以及系统配置的文档说明。
测试脚本创建 - 测试脚本必不可少，有了脚本就能够以一种可重复并受控制的方法根据需要重复运行测试，从测试单用户交互开始，直至调整为模拟负载测试。用户事务的插入、用户思考时间、用户任务的进度以及参数化事务输入都包含在脚本内。
测试执行 - 使用一个或多个加载测试工具执行测试时，要确保当前只有要测试的目标应用程序正在运行，而且也要确保整个测试周期的应用程序数据和系统配置的一致性。这样才能生成可靠的测试结果。
结果的分析 - 分析、比较和关联诸如响应时间和系统行为之类的关键衡量指标、估计由测试用例或组件故障所导致的异常结果，并评估容量阈值和限制。
通常，简单的 Web 应用程序和服务相对而言更易于进行脚本测试和性能测试。而富客户端应用程序（如 ArcMap 或基于 ADF API 的 Web 应用程序）对于测试的挑战性就大得多。下表列出了针对各应用程序架构所需执行的测试的相对等级：不同应用程序架构下的测试强度等级

类别	工作强度	注意事项
富客户端应用程序 (ArcMap)	高	需要编写屏幕像素点击脚本
Web 应用程序（JavaScript、Flex 和 Silverlight API）	中-低	对 REST 接口进行无状态调用非常容易，但模拟应用程序接口内的用户活动则可能更具挑战性。
Web 应用程序（NET 和 Java ADF）	高	需要管理应用程序状态及 Ajax
移动应用程序	中
服务	低	REST 和 SOAP 服务对于直接测试而言最为简单

Esri 测试过程

部署系统

验证系统配置与部署方案是否匹配
功能性测试应用程序的完整性、可靠性和合理性以及能否呈现所规定的业务需求和功能规格至关重要。

系统调优

在测试前需确保实施如下最佳实践及调优操作MXD 调优
数据库调优

开发测试方案

综合性测试方案对于测试的成功是很有必要的，包括采访应用专家
定义要测试的工作流和事务，包括思考时间
定义目标用户负载，如并发用户、每小时事务量和使用模式
定义使用模式的权重
编写测试环境的配置说明
验证成功条件
定义要报告的必要度量

测试脚本

根据“测试方案”规范开发测试脚本
包含验证规则

负载测试设计

选择适当的测试客户端计算机
定义要收集的必要度量
实施虚拟用户的分步加载
实施分步持续时间
实施进度

测试执行

初始运行将验证负载测试参数是否产生预期行为
验证其他测试的结果

分析和报告

最后一步就是要分析、比较和关联诸如响应时间和系统行为之类的关键衡量指标、估计由测试案例或组件故障所导致的异常结果，并评估容量阈值和限制。查看事务响应时间以最长的响应时间确定主体事务

查看层度量并标识潜在的瓶颈层Web 服务器
应用程序服务器
数据库服务器

查看每台计算机的系统度量并查找潜在的硬件资源瓶颈CPU
RAM
DISK
Network

查看各层的系统矩阵和应用程序矩阵（包括误差矩阵）并确定潜在的层瓶颈测试客户端
Web 服务器
GIS 服务器
数据库服务器

编写汇总信息的报表