ArcSDE性能分析-关于服务器的选型和并发用户预估

经常会有用户咨询，我的XXXX的服务器，能否支持多大的并发用户，这些问题的确不好回答，因为用户的数据库组织、用户系统需求、用户的业务等都会有所影响，幸好Esri出了一个关于系统设计方面的文档，截取一些关于ArcSDE关于服务器CPU以及并发用户的相关资料，以供用户参考。





图上

蓝颜色为：服务连接

绿颜色为：直连

可见直连比服务连接要快

以上测试版本应该为ArcSDE9.2-ArcSDE9.3 ，大家在选型过程中可以依照自己的相关硬件或者并发用户要求。仅供参考！

关于一个ArcGIS系统性能设计的参考：http://www.wiki.gis.com/wiki/index.php/System_Design_Strategies

-------------------------------------以下为ArcGIS Server预估用户数量-----------

ArcGIS Server 的强大优势在于它可以向位于不同地点的多个用户提供 GIS 功能。在规划 GIS 服务器时，应尽量确定出使用该系统的用户数量以及支持这么多用户所需要的硬件数量。此外，诸如是否可能出现大量用户集中使用的现象等其他因素也会对决策造成影响。如果您无法添加更多硬件，则可以尝试通过调整服务配置来容纳更多用户。

通过服务器对象容器 (SOC) 计算机容纳用户

服务器将在服务器对象容器 (SOC) 计算机上完成 GIS 作业。处理负荷较高时，SOC 通常将先于服务器对象管理器 (SOM) 或 Web 服务器达到 100% 的 CPU 使用率。因此，确定出要部署的 SOC 计算机的数量是便于容纳用户的一个重要决策。

要选择 SOC 计算机的所需数量，应考虑到需要同时使用同一项服务的用户的最大数量。通常，一个 SOC CPU 支持四个服务实例同时运行。这意味着最多允许四个用户同时使用这些服务。但处于运行状态但尚未使用的服务不算在内。GIS 操作一完成，ArcGIS Server 开发人员便会加入代码以便发布服务器上下文。

上述数字 4 仅供参考，具体数量视用户在服务器上所执行操作的复杂性和所使用的数据而定。系统启动并运行后，用户便可借助日志文件及服务器统计数据对系统的容量和性能做出进一步调整。如果您发现在系统负荷达到峰值时向 SOC 发出的正常请求超时，同时 CPU 使用率接近 100%，那么在 SOC 层添加额外的 CPU，系统的性能可能会有所提高。

在对服务器处于高负荷下的性能进行测试或得出结论之前，请确保已将服务器配置为避免对每个 Web 服务请求都进行模拟。并发请求数量达到每秒 25 个或更多可能导致本地安全机构子系统服务 (lsass.exe) 过载，从而导致系统性能大大降低。在 ESRI 知识库文章 32620 (Windows
Server 2003) 或 32622 (Windows XP) 中，您可以查阅到应对此状况的方法。

如要获取关于调整系统容量的具体方法，请参阅系统设计策略白皮书，网址为http://www.esri.com/systemdesign。

通过调整服务器属性容纳用户

如果无法向系统中添加硬件，还可以通过合理地配置服务属性来容纳更多用户。

例如，所有服务都具有实例最大数属性，表示可同时运行的服务实例的最大数量。作为管理员，您应当尽量确定出在性能水平差强人意的前提下，多少个服务配置实例可以满足用户预期需求。这是一个复杂的评估过程，需要计算每个客户端使用服务的平均时间、预期的客户端数量、客户端请求频率以及每个请求所需的处理强度。

反复试验也许才是确定某项配置中所需服务的数量的最佳方法，因为发现客户端等待时间较长或请求超时时，便需要调整可用服务的数量或调整应用程序使用这些服务的方式。一旦确定出支持各客户端的服务的数量，就应将该数量设定为该项配置的最大实例数。这样便可将剩余系统资源分配给其他服务配置及其所支持的客户端。

另外，各项服务还具有最小实例数属性。该属性表示已经创建且可供使用的服务的数量。如果您担心可能会发生多个用户同时使用一项池化服务的状况，则可考虑减少该服务的最小实例数。如果您愿意，甚至可以将最小实例数设置为零。

有时，外部事件的发生可能会促进对某项特定服务的使用。例如，发生自然灾害时，某个应急管理应用程序可能会面临对于某项服务的请求数量突增的情况。为了最大限度地利用 ArcGIS Server，最好增大该项服务的最大实例数以便消耗掉所有可用的服务器资源。这样，该服务便可利用整体配置了。ArcGIS Server 为您提供了池收缩功能，借助该功能可自动减小不常用服务配置的实例数量，从而为常用配置提供更多资源。

了解有关池收缩的详细信息

您还应当考虑到用户使用服务的时间长度。处理某些服务器请求的强度可能要比处理其他请求时大一些。大量处理强度较小的服务请求并不比少量处理强度较大的请求更容易导致服务器瘫痪。每项服务均具有最长等待时间属性和最长使用时间属性。如果用户发出的服务请求屡次超时，则应考虑延长最长等待时间或增大可用服务实例的数量。

您可以通过日志文件和服务器统计数据来确定是否请求过多而导致超时以及是否服务在其最长使用时间范围之外被使用。您还可以使用管理器或 ArcCatalog 调整可用服务的数量和某项服务的最长使用时间。