ArcGIS workload capacity, availability and recoverability
Use representative demand
Named users, active sessions, concurrent requests and throughput are not interchangeable counts. Record the relevant service mix, request cost, response size, peak demand and acceptable response time. A simple CPU estimate can relate per-request CPU service demand to request rate and a target utilization under supplied units. It is a bounded model rather than a complete procurement decision. Round and reserve capacity appropriately for actual resource and failure constraints; a fractional theoretical result is not automatically a sufficient whole-server design.
Follow shared dependencies
CPU, memory, disk I/O, database behavior, network paths and application design can constrain performance together. A map cache, service pool and request pattern affect what work reaches the origin. Splitting heavy processing from interactive services can reduce contention under an actual supported design. Do not presume that every GIS-server machine is stateless or can be placed in a generic autoscaling group without supported configuration/state handling. Benchmark assumptions and hardware normalization cannot guarantee linear scaling.
Separate availability from recovery
Redundant machines and health-aware routing can help tolerate covered failures, but shared storage, identity, networking and management can remain failure dependencies. Two eight-core machines do not provide twelve surviving cores after one fails. High availability does not replace independent recoverable backups or protect against every corrupted or deleted record. RTO and RPO describe recovery objectives under the intended service/data boundary; an objective is not a measured guarantee that a particular backup schedule or replica will meet it.
Test the intended outcome
Use a supported recovery design that covers portal/server configuration, relevant managed data and separately managed registered databases/files as needed. A webgisdr backup has a documented scope and does not automatically include every external data source, specialty store or third-party dependency. Verify recovery prerequisites, restore procedure, versions, identities and actual application outcomes through an authorized test. These exercises run no load, backup, failover or restore, and they provide no universal availability guarantee, operational setpoint or full professional system-design assessment.