Publishing and Scaling a Utility Network for 250 Editors
An electric utility publishes a utility network with 1.4 million features to ArcGIS Enterprise. The portal is federated with two GIS servers. The utility network was created in an enterprise geodatabase and registered as a data store. Publishing from ArcGIS Pro takes 50 minutes and sometimes fails at 90 percent with a timeout. After publishing, 250 editors across four regions use one web map and one feature service. Traces that take 8 seconds in ArcGIS Pro take 45 seconds in the web map, and the service restarts during peak use. All editors work in the default version because the utility wants immediate updates. The utility has 16 GB RAM per GIS server and no dedicated geodatabase server; the geodatabase and GIS server share the same machine.
1. Identify the likely causes of the 90 percent publish timeout and the service restarts. Would you let all 250 editors edit the default version? Justify.
Read the worked answer
The publish timeout is likely resource contention during service creation, not a data error: 1.4 million features, a shared GIS and geodatabase machine, and only 16 GB RAM can exhaust memory and database connections before publishing completes. The 90 percent point often corresponds to service startup and capability initialization, so a timeout there suggests the server cannot start the service within the allowed time. The restarts during peak use point to memory pressure or too many concurrent service instances. I would not let 250 editors edit the default version. The default version is the published integration version; concentrating all edits there increases lock contention, long transactions, and posting risk. Use named versions per region or district, reconcile and post on a schedule, and keep the default version as the stable published view. That reduces contention and makes failures easier to isolate.
2. Recommend service and sharing configuration changes to improve trace performance and stability.
Read the worked answer
Separate concerns. Publish one feature service with the utility network capability and share it through focused web maps rather than one map for all 250 editors. Set minimum and maximum instances based on server cores and memory, and increase server heap if memory allows; 16 GB shared with the geodatabase is a constraint, so a dedicated geodatabase server or more RAM is the durable fix. Use saved trace configurations on the service, limit trace extent where possible, and prefer subnetwork-based traces that use the stored subnetwork state. Validate network topology and update subnetworks before peak use. In the web maps, apply scale dependencies and filters so editors do not draw the entire 1.4 million-feature network. Share services to regional groups with appropriate permissions, and avoid republishing for every change; publish once and use versioned editing.
3. Outline a phased migration from default-version editing to a versioned workflow for 250 editors without disrupting field work.
Read the worked answer
Pilot with one region and a small crew. Create a district version and child versions for crews or individuals, set permissions, and train editors to save, stop editing, and reconcile on a schedule. Keep the default version as the published integration version and post only after child versions are reconciled and validated. Monitor conflicts, trace performance, and posting duration during the pilot. Then roll out region by region, adjusting version granularity if conflict rates are high. Publish job aids for version creation, reconciliation, and posting; use version manager for supervisors; and schedule validation and subnetwork updates before peak periods. Do not migrate all 250 editors at once, because a failed rollout would leave field crews without a trusted published view.