Drawing Performance: Pressure Subnetwork

856
8
Jump to solution
04-05-2024 05:23 AM
MichaelParma
Regular Contributor

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?

MichaelParma_0-1712319532452.png

Thanks,
Michael Parma

0 Kudos
1 Solution

Accepted Solutions
RobertKrisher
Esri Regular Contributor

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.

View solution in original post

8 Replies
RobertKrisher
Esri Regular Contributor

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.

MichaelParma
Regular Contributor

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

0 Kudos
MichaelParma
Regular Contributor

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.

MichaelParma_0-1713533125436.png

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

 

0 Kudos
MikeMillerGIS
Esri Frequent Contributor

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?

0 Kudos
MichaelParma
Regular Contributor

Hi Mike,

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

0 Kudos
MichaelParma
Regular Contributor

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.

0 Kudos
gis_KIWI4
Frequent Contributor

@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. 

0 Kudos
RobertKrisher
Esri Regular Contributor

@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.