调整服务以满足用户需求
默认的服务属性值可能无法满足用户的需求。 当用户数量较多或他们向 ArcGIS Server 站点发送大量请求时，情况尤其如此。 本主题概述了可用于优化配置服务的概念、属性和技术。
了解服务实例
对 ArcGIS Server 站点中的某个服务发出请求（例如平移地图、导航至某个地址或使用渲染规则显示图像）时，该请求将由在服务器计算机上运行的已发布服务的实例进行处理。 服务实例由名为 ArcSOC 进程的 Esri 专有服务器进程提供支持。 每个 ArcSOC 进程运行时都需要占用一定量的计算机内存。
如果 ArcGIS Server 站点上有许多服务，且每个服务使用一个或多个持续运行的服务实例，则计算机可用内存最终将达到限值。 运行服务实例也会给您的组织带来能量消耗，如果您在云基础架构上部署 ArcGIS Server，则每个正在运行的服务实例都会给您带来直接的货币成本。
因此，ArcGIS Server 管理员有必要监控其站点运行的实例数，并在性能受到内存使用量抑制时限制所运行的实例数。
用户希望在与服务交互时能够快速获得结果（包括借助服务构建的产品，例如 Web 地图和应用程序）。 处理服务收到的流量时需要足够的 ArcSOC 进程。 但是，如果配置的服务器资源超过了服务所需，则会浪费计算机内存、能源和资金。 对于管理员来说，在不影响性能的前提下，将运行的服务实例数量减少到所需要数量是一个理想的目标。
共享和专用服务实例
您可通过 ArcGIS Server 对从 ArcGIS Pro 发布到 ArcGIS Server 站点的每个兼容地图或影像服务使用共享实例或专用实例。 使用共享实例可以通过池化多个活动服务器进程以供多个服务使用的方式来节省内存使用量。 此外，专用实例可让服务在通过一个或多个服务器进程处理请求时始终可用，同时也是经常性或计算密集型请求的理想之选。
对于新部署的 ArcGIS Server，共享实例是默认选项。 管理员可以选择默认实例类型（无论兼容地图服务最初应使用共享实例还是专用实例）以及随时更改单个服务的实例类型。
提示：
要确定服务是从哪个应用程序发布的，请参阅 ArcGIS Server Manager 应用程序中每个服务的服务运行时和实例类型属性。
以下限制条件用于限制可以使用共享实例池的服务：
仅地图和影像服务可以配置为使用共享实例池。 不支持其他服务类型，例如地理处理服务。
仅可启用以下功能：地图、影像、要素访问、WFS、WMS 和 KML。 在将专用服务转换为共享服务之前，请先关闭所有其他功能。
使用专用实例的地图或影像服务通过指定的 ArcSOC 进程池运行。 该池中的进程不会用于任何其他服务。 使用共享实例的地图或影像服务运行在一个 ArcSOC 进程池中，该进程池也供其他所有共享实例服务使用。 默认情况下，每个共享实例 ArcSOC 会缓存 50 个最近使用的服务，以便随时准备处理请求。 当用户请求新服务时，如果共享实例 ArcSOC 缓存的服务数量已达到最大值，该 ArcSOC 将卸载最近最少使用的服务并加载新服务。 如果用户经常请求超过 50 个共享实例服务，您可以增加每个共享实例的默认缓存服务数量。
使用每个实例类型的时机
通常推荐使用共享实例而非专用实例。 共享实例提供了更高的整体效率，因为它们具有相同的中位数性能和吞吐量，但消耗的系统资源显著减少。
在以下两种情况下，建议使用专用实例：
出于业务原因，需要少数服务相比其他服务具有更高的性能和可扩展性。
当共享实例不支持某些功能（例如非线程安全的 SOE 或公共设施网络）时。
将服务指定为专用实例并不会自动提升性能。 要通过专用实例提高性能，您还必须减少可用于共享实例的实例数量，并仔细设置专用服务的实例数量。 将过多的服务指定为专用实例可能会降低性能。 建议每个站点的专用地图或影像服务尽可能少。
地图和影像服务属于 CPU 密集型。 通常，专注于地图和影像服务的 ArcGIS Server 的吞吐量受限于 CPU 内核数量。 如果您的服务器计算机具有 8 个内核，且您的所有服务均为共享实例，则当该计算机同时处理 8 个请求时，最大吞吐量可能会达到峰值。 ArcGIS Server 可以处理更多请求，但这些额外的请求将共享 CPU 资源。 所有使用共享实例的服务都具有相同的优先级，并可以使用服务器的全部 CPU 性能。
专用实例适用于需要持续稳定性能的服务，即使这会导致其他服务性能下降。 例如，如果您的计算机有 8 个内核，您可以通过将该服务的最小和最大专用实例数设置为 4，从而为其单独留出其中一半的内核。 为了确保始终至少有 4 个内核可用于该专用服务，您可以将共享实例的数量减少到 4，这样它们使用内核的数量就不会超过 8 个内核中的另一半。
ArcGIS Server 允许超额分配实例。 这意味着即使计算机只有 8 个内核，您也可以分配多于内核数量的实例。 虽然可以进行超额分配，但这会使性能难以预测和控制。 采用 10% - 20% 的超额分配可能会提高效率，但过高比例的超额分配很可能会损害性能。 与其超额分配专用实例，不如通过将部分专用服务转换为共享实例来获得更好的性能。
最小和最大服务实例数
如果服务正在使用专用实例，则可以调整每台计算机允许的最小和最大实例数。 这些参数可帮助您的站点服务适应交通流量波动。
最小实例数属性表示每台 ArcGIS Server 计算机上已创建且可供服务使用的专用实例数。 例如，如果将此参数设置为 3 个实例，则在任何给定时间，ArcSOC 进程中始终至少有 3 个正在运行的实例，即使该服务没有收到任何请求也是如此。 如果您担心可能会发生多个用户同时使用一项服务的状况，则可考虑减少该服务的最小实例数。
最大实例数属性表示在任意指定 ArcGIS Server 计算机上运行的该服务的最大实例数。 作为管理员，需确定出在性能水平可以接受的前提下，多少个服务配置实例可以满足用户预期需求。
建议通过对服务器进行持续监控确定服务配置所需的实例数。 如果客户端等待时间较长或请求超时，则可能需要调整可用实例数或调整应用程序使用这些实例的方式。
考虑用户使用服务花费的时间长度。 服务器上某些请求的使用比其他请求工作量更大。 相比于少量高强度的工作请求，服务器处理大量轻量级服务请求可能并不会太困难。 每个服务都有最长等待时间属性和最长使用时间属性。 如果用户发出的服务请求屡次超时，则应考虑延长最长等待时间或增大可用服务实例的数量。
确定支持客户端的实例数量后，使用该值除以部署中 ArcGIS Server 计算机的数量，然后将服务配置的最大实例数设置为所得结果。 例如，如果需要最多十个服务实例能够同时处理其请求，且有两台 ArcGIS Server 计算机可用，则将最大实例数设置为五。
每个实例都会消耗内存，即使该服务未被使用。 将每台计算机的最小实例数设置为低于每台计算机的最大实例数，可以让您在不使用内存时释放内存。 此功能通常对性能的影响较小。 当需要启动新实例时，请求可能会出现延迟。 为防止这种延迟，您可以将每台计算机的最小实例数设置为等于每台计算机的最大实例数。
使用日志和服务器统计数据可确定过多请求是否会导致超时，以及使用的服务是否超出最长使用时间。 使用 Server Manager 调整可用服务实例数以及服务的最长等待时间和使用时间。
服务实例池化
ArcGIS Server 发布的所有服务都是池化服务。 这意味着可以在多个应用程序会话之间共享服务的实例。
使用池化服务实例的应用程序仅在完成一个请求期间内使用该实例（例如，绘制地图或对地址进行地理编码）。 请求完成后，应用程序释放其对服务的引用，并将其直接返回给可用的实例池。
服务实例回收
服务回收操作可销毁那些不可用的服务并将其替换为新服务；也可回收被已过时的服务所占用的资源。
服务通常在多个应用程序和那些应用程序的用户之间共享。 在重用过程中，服务可能会发生一些问题，从而导致其无法供应用程序使用。 例如，应用程序可能会错误地修改服务状态，或者应用程序可能会错误地占用对服务的引用，使其无法用于其他应用程序或会话。 在某些情况下，服务也可能会损坏而无法使用。 回收操作可用于将服务池保持为最新状态并迁出所有过时或不可用的服务。
回收期间，服务器会销毁服务配置中的每个实例，之后再重新创建。 回收作为服务器的后台进程执行。 尽管屏幕上不会显示任何用于告知您回收正在进行的信息，但您可在日志文件中查看所有与回收相关的事件。
回收操作将销毁服务的所有运行中的实例，并重新创建，无论这些实例的个数是否高于指定的最小值。 要使运行中的实例数定期返回到所指定的最小值，您必须停止服务并重新启动。 执行这一过程的最好方法是创建一个可用于执行自定义 ArcGIS Server 管理 API 命令行可执行文件的 Python、shell 或 Windows 批处理脚本文件。 此自定义可执行文件将包含服务器名称、服务名称、服务类型，以及确定服务是否应按命令行参数启动或停止等信息。
回收事件之间的间隔时间被称为回收间隔。 默认的回收间隔为 24 小时，可在服务编辑器对话框中对其进行更改。 您还可以选择初次回收配置的时间。 从该时刻开始，每当达到回收间隔时间时，即会自动执行回收操作。
回收服务时，每次回收一个实例，这样可确保实例始终保持可用状态，而且可分摊为每个服务创建新实例时导致的性能损失。 回收按照随机顺序进行；但客户端当前正在使用的服务实例在被释放之前将不会被回收。 这样，执行回收操作就不会对使用服务的用户造成任何干扰。
如果回收期间可用实例不足，请求将排队等候，直到实例变为可用为止。 如果在此期间达到了服务的最长等待时间，日志将记录通常所记录的消息。
检查无效的数据连接
服务实例处于空闲状态时，服务器管理员很难确定与源数据的连接是否得到成功维护。 ArcGIS Server 具有内置机制，可用于检查与企业级地理数据库的无效连接。 这些检查可避免您的服务在与数据库的连接被删除或中断之后出现无响应的情况。
注:
对无效数据连接检查的支持不包括文件地理数据库。
通过在 ArcGIS Server Manager 中打开服务编辑器对话框的进程选项卡，然后选中定期检查并修复空闲实例的数据连接复选框，启用数据连接有效性检查。 还需要指定以分钟为单位的时间间隔，将以该时间间隔自动验证服务连接的有效性（并在需要时进行修复）。 默认值 30 分钟通常比较合适。
此外，如果您的服务闲置了一段时间后，防火墙关闭了与企业级地理数据库连接的端口，启用这些检查同样可能有所帮助。 在这种情况下，防火墙超时设置可能会对您所选择的时间间隔造成影响。
超时
解各种可用的服务超时值有助于您保持服务正常工作和可用。 这些值在服务编辑器对话框的池化选项卡中提供。
客户端在获取对服务的引用之后，会在释放服务之前的特定时段内使用该服务。 使用时间是从客户端获取对服务的引用开始到释放此服务所经历的时间。 为避免客户端过长时间地占用对服务的引用（即客户端未正确释放服务），每个服务都具有一个客户端可使用一个服务的最长时间的属性。 如果客户端占用某一服务的时间超过最长使用时间，此服务将被自动释放，而客户端将失去对此服务的引用。
抢先版本：
创建新服务时，最长使用时间的默认值是 600 秒（10 分钟）。 但是，在随各 ArcGIS Server 站点提供的预生成 PublishingTools 服务中，最长使用时间设置为 3600 秒（60 分钟）。 这是为了应对要将大量数据复制到服务器的发布作业。
通过配置最长使用时间还可防止服务被用于执行过量的工作（超出管理员计划的工作量）。 例如，由一个应用程序使用的执行地理数据库检出的服务可能具有 10 分钟的最长使用时间。 与之相比，仅用于在一个应用程序中绘制地图的单图层服务的最长使用时间可能只有 1 分钟。
当服务正在使用的实例达到最大实例数时，请求服务的客户端将排队等待，直至另一个客户端释放了其中的某一服务。 从客户端请求服务开始到获得服务的时间为等待时间。 每个服务都具有一个客户端获取一个服务将等待的最长时间属性。 如果客户端的等待时间超过服务的最长等待时间，请求将超时。
另一个超时指明了空闲实例可保持运行的最长时间。 客户端停止使用服务期间，这些实例将仍然运行在服务器上，直到其他客户端需要实例为止。 正在运行但未被使用的实例仍会占用服务器上的一些内存。 您可以将运行中的服务数降至最低，以通过缩短此空闲超时来节省内存，默认的空闲超时为 1800 秒（30 分钟）。 空闲超时过短的缺点在于，如果运行中的所有服务都出现了超时，那么后续的客户端便需要等待创建新实例。
当在 GIS 服务器中创建服务实例时（无论是由于服务器启动还是响应客户端的服务器请求），初始化该服务实例所需的时间称为其创建时间。 GIS 服务器具有一个启动超时值，用于指定启动尝试可经历的时间，超过该时间后，GIS 服务器将假定服务的启动处于挂起状态并取消创建服务实例。 默认值为 300 秒（5 分钟）。
GIS 服务器同时在内存和服务器的日志中记录有关等待时间、使用时间和在服务器内部发生的其他事件的统计数据。 服务器管理员可使用这些统计数据确定诸如某一服务的等待时间是否很长的问题，如果过长则可能表示需要增加该服务的最大实例数。
架构中可能会遇到其他超时，这些超时会导致指定的服务超时值与客户端遇到的实际超时之间存在差异。 例如，托管 ArcGIS Web Adaptor 或网络负载均衡器的 Web 服务器会施加影响服务的超时。
注:
如果站点承担的负载非常高，则指定的超时值与客户端遇到的超时之间会有差异。
限制用户可对服务执行的操作
为了便于控制 Web 服务的使用方式，每种类型的服务都具有一组允许的操作。 每个操作都包含一系列以组为单位进行启用或禁用的方法。 Web 服务的客户端只能调用允许的操作方法。
假设您要允许 Web 制图服务的客户绘制地图但不查询地图图层的数据源。 则需要禁用“数据”操作并确保允许进行“地图”操作。
此讨论中特别关注要素服务，因为它们用于对 GIS 数据执行基于 Web 的编辑。 要素服务具有一组可用于限制编辑功能的附加操作。 您可以访问 ArcGIS Server Manager 中服务编辑器对话框的要素访问选项卡以启用或禁用这些操作。 也可以通过强制执行基于所有权的访问控制来防止用户编辑不是由其最初创建的要素。
有关允许对各种服务类型执行的操作，请参阅服务类型。
服务优化调整场景
以下场景提供了一些管理员如何优化调整服务以满足用户需求的实际示例。
场景：服务响应时间缓慢
您的组织中的某个用户已经与您联系，该用户说自己正在遇到特定地图服务的不可接受的显示时间。 对地图服务进行测试后，您发现地图服务中的特定图层的绘制速度较慢。 要进一步调查，您使用服务器日志解决地图服务性能问题，并隔离与此地图服务有关的信息。
潜在原因 #1
审核服务器管理器日志时，您发现服务中一个图层（或多个图层）的绘制时间过长。
#1 的通用解决方案
使用以下最佳做法优化地图的性能：
使用按比例渲染。
移除未使用的图层和数据框。
将验证用于定义查询。
简化图层符号系统
如果可能，考虑使用缓存地图（例如，如果数据不频繁更改）。
在查看服务、实施优化提示和重新发布服务后，您和您的同事看到在地图服务的响应性方面有了显著改进。
潜在原因 #2
服务器管理器日志指示对服务中某个图层的滞后网络访问可能会降低服务性能。
#2 的通用解决方案
使用适用于数据访问和管理的以下最佳做法，最大限度缩短网络延迟和优化服务性能：
确定是企业级地理数据库还是文件地理数据库最适合此特定服务。 有关详细信息，请参阅发布服务的数据库注意事项。
有关发布提示，请查看影像服务的数据存储场景。
在查看服务、实施数据访问和管理提示和重新发布服务后，您和您的同事看到在地图服务的响应性方面有了显著改进。
场景：确保计算机资源充足
您已经在创建 Web 应用程序之后创建了一个高效搜索，并希望在本周即将到来的既定日期将其提供给更广泛的受众。 因为您预估到用户会对此应用程序中的服务发出大量请求，所以您想要确保有足够的计算机资源为此应用程序的使用提供支持。
要分配足够的服务器计算机资源来支持此 web 应用程序的高使用率，您将查看 ArcGIS Server 统计数据来确定不频繁使用的服务并相应地调整服务属性，从而容纳此应用程序的使用者。 因此，您将需要针对要在此 Web 应用程序中使用的服务相应地调整服务属性。
潜在解决方案
管理并微调服务属性，为您的站点分配资源。 例如，考虑到用户使用服务的时间长度。 服务的当前使用是否超出其最大使用时间？ 最终用户是否由于对某个服务的过多请求而遭遇超时？
使用以下建议作为指导原则，调整服务属性，以便预估和容纳最终用户：
确定最频繁使用的服务并增加每个服务的最小实例数。 此做法将会减少最终用户的等待时间。
将当前使用专用实例的服务迁移到可使用共享实例池的配置。
适当增加最小和最大实例数、等待时间、空闲时间和使用时间有助于缓解最最终用户造成的延迟问题。
适当减少最小和最大实例数、等待时间和空闲时间可以为最需要这些资源的服务释放系统资源。