nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ArcGIS Server 10.7.1: What is the main reason for slow rendering of map services sourced from polygon enterprise geodatabase?

JamalNUMAN

I couldn’t figure out the main reason for slow rendering of map services sourced from polygon enterprise geodatabase.

What suggestions to increase the performance in rendering of map services sourced from polygon enterprise geodatabase?

Find more posts tagged with

Accepted answers

DavidHoy

Jamal NUMAN‌

Have you had any success in improving the performance of the Map Service?
To diagnose properly, we need to know a few more details:

- does an equivalent service with the same data in a file data source work faster?

this may indicate data access problems from the server to the database

- is the enterprise geodatabase in the same data centre as the ArcGIS Server?

it is generally a bad practice to try to connect to an Enterprise Geodatabase (Oracle/SQL Server/PostgreSQL etc) via SQL clients across a high latency network
- each draw of an individual layer may require >10 sequential SQL queries - multiple layers compound the delay as they draw one at a time. with even (say 50ms query latency, you may be waiting many seconds for just the querying and return of results - before the rendering even begins.

- does the layer draw faster in a desktop application (ArcMap or Pro) using a direct database connection rather than accessing the service?

it may be that the path from the Server to the database may be slower than the Desktop client to the database

- Are you seeing bad performance only when trying to draw many polygons?

if your service is defined to draw lots of detail at small (zoomed out) scale, you may need to ask if the detail is relevant. You may be asking the server to render many thousands of individual vertices - even when these all are actually rendering to the same pixel on your screen! Lots of vertices = a large data packet returned to the server (transfer time + lots of server time rendering individual vertices redundantly in the map image)

- Are you seeing slow draw even when zoomed in close and only showing part of one or a few polygons?

This may also be a symptom of a too finely detailed polygon. You may benefit from simplifying the boundaries of you polygons to remove vertices that dont add relevant to the shape.
Sometimes, you may only see a small part of the polygon's boundary, but unfortunately, the SQL query will still be returning the entire feature to be rendered.

There are more possible reasons, but let's see how you go with this for a start.

All comments

DavidHoy

Jamal NUMAN‌

Have you had any success in improving the performance of the Map Service?
To diagnose properly, we need to know a few more details:

- does an equivalent service with the same data in a file data source work faster?

this may indicate data access problems from the server to the database

- is the enterprise geodatabase in the same data centre as the ArcGIS Server?

it is generally a bad practice to try to connect to an Enterprise Geodatabase (Oracle/SQL Server/PostgreSQL etc) via SQL clients across a high latency network
- each draw of an individual layer may require >10 sequential SQL queries - multiple layers compound the delay as they draw one at a time. with even (say 50ms query latency, you may be waiting many seconds for just the querying and return of results - before the rendering even begins.

- does the layer draw faster in a desktop application (ArcMap or Pro) using a direct database connection rather than accessing the service?

it may be that the path from the Server to the database may be slower than the Desktop client to the database

- Are you seeing bad performance only when trying to draw many polygons?

if your service is defined to draw lots of detail at small (zoomed out) scale, you may need to ask if the detail is relevant. You may be asking the server to render many thousands of individual vertices - even when these all are actually rendering to the same pixel on your screen! Lots of vertices = a large data packet returned to the server (transfer time + lots of server time rendering individual vertices redundantly in the map image)

- Are you seeing slow draw even when zoomed in close and only showing part of one or a few polygons?

This may also be a symptom of a too finely detailed polygon. You may benefit from simplifying the boundaries of you polygons to remove vertices that dont add relevant to the shape.
Sometimes, you may only see a small part of the polygon's boundary, but unfortunately, the SQL query will still be returning the entire feature to be rendered.

There are more possible reasons, but let's see how you go with this for a start.

JamalNUMAN

Thank you David for the very useful input.

But what if the service gets extremely slower as it is displayed in full extent mode? Does this indicate for something else other the points you have already provided?

DavidHoy

sanity check - at full extent - how many records are you expecting to be drawn?
- if many thousands - or the records you are drawing are complex with many vertices - then this is a large amount of data being extracted from the database and it's not unexpected this may take a long time
  - can you provide some metrics?
    # of records
    Size of the feature class (copy it to an fgdb and see how big that is)
    how long does it take to draw at full extent?
    how long to draw at (say) half the extent? - is this proportional to the time at full extent

JamalNUMAN

Thank you DavidHoy.

I’ll be considering the points you have already highlighted and find out how the performance is impacted

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.