topic Re: Drawing Performance: Pressure Subnetwork in ArcGIS Utility Network Questions

Drawing Performance: Pressure Subnetwork

MichaelParma — Fri, 05 Apr 2024 12:23:21 GMT

I'm curious about options to improve drawing performance of the subnetworks when the aggregated geometry is saved. As a specific example, a client has a water system with 3 subnetworks in the pressure tier. Using the default template symbology from the solution, draw times in the web map are <2 seconds with all layers turned on excluding the water network/water pressure. Turning on this layer consistently pushes draw times over 30 seconds. This is confirmed in the ArcGIS Server logs that performance is isolated to this layer.

I suspect it is an issue with a complex "spider web" geometry over a wide area that thus lacks a useable spatial index (compared to other features). I suppose a possible workaround is to forgo the water network/water pressure feature and instead symbolize the water lines (mains, services) again based on the pressure subnetwork name. Anyone have suggestions on how to improve the drawing performance of this layer?

Thanks,
Michael Parma

Re: Drawing Performance: Pressure Subnetwork

RobertKrisher — Fri, 05 Apr 2024 13:33:24 GMT

It looks like you are including the services/laterals in your subnetwork line. This is not recommended since it greatly increases the complexity and draw time of the layer. Configure the subnetwork line to only include the mains and you should see draw times improve.

Re: Drawing Performance: Pressure Subnetwork

gis_KIWI4 — Wed, 10 Apr 2024 10:50:38 GMT

@RobertKrisher - I too have had a similar experience as the OP.
The subnetline layer seems to struggle when added to the webmap and setting a definition query to filter out the LV subnetworks (service lines and LV distribution) makes it much worse.

I have gotten away by setting the symbology for the LV subnetwork to a "blank" so its still within the map but it is not cluttering it.

Re: Drawing Performance: Pressure Subnetwork

RobertKrisher — Wed, 10 Apr 2024 13:29:48 GMT

@gis_KIWI4 That sounds like a separate issue. If you're noticing a performance hit when you query the layer using a particular attribute, and that query is something you intend on using a lot, have you considered adding an index to that field? As an example, you could add an index to the tier name field (which is used as the subtype for the layer) and use a subtype group layer to control scale suppression.

Re: Drawing Performance: Pressure Subnetwork

MichaelParma — Thu, 11 Apr 2024 19:54:58 GMT

Thanks, Robert. I had thought about dropping the laterals from the subnetwork line. In this case, I'm using Esri's base model downloaded from the solutions page. I'm trying to avoid altering the solution configuration to stay as "true" as possible for demonstration purposes.

Given the performance is so slow, I may have to resort to a deviation.

Thanks,
Mike

Re: Drawing Performance: Pressure Subnetwork

MichaelParma — Fri, 19 Apr 2024 13:26:22 GMT

Hi Robert,

As suggested, we dropped the topology and removed the laterals from the subnetwork line definition. After enabling the topology and restarting the service, that part seems to have worked well. However, now we are receiving an error that appears to be related to attribute rules and an L### prefix in front of the feature class name. This seems odd as the only change we made we the subnetworkline definition.

Let me know if you have ideas or if this warrants a separate post. I'm certain I've seen this before but can't find the resolution again.

Many thanks,
Mike

Re: Drawing Performance: Pressure Subnetwork

MikeMillerGIS — Fri, 19 Apr 2024 13:30:37 GMT

The rule should have monikerized the table name, so it should be looking for a guid. Seeing the table name means that the monikerization did not happen. So the SOC could not find the table on start. If you restart the service, does it fix it?

Re: Drawing Performance: Pressure Subnetwork

MichaelParma — Fri, 19 Apr 2024 13:39:06 GMT

Hi Mike,

We restarted the service and even republished the service, but the issue persists.

Re: Drawing Performance: Pressure Subnetwork

MichaelParma — Mon, 22 Apr 2024 14:55:01 GMT

Just to close the loop on this one. We ended up going in to the datbase and selecting the "Exclude from Application Evaluation" from each attribute rule and this resolved our resolve. Now, I'm not sure why we had to do that when it was working fine 20 minutes earlier. But that's a different story for another time.