Intermittent map service / image redraw performance

02-24-2014 07:43 AM
by Anonymous User
Not applicable
Original User: salestm

While this is a long description, want to share all info gathered to date and ask for guidance/feedback...

We have a map service that contains a over a dozen common layers used in multiple sites/viewers (using site reference). This map service is duplicated on an internal (only) AGS instance and external / public instance. The map services (from both instances) are dynamic accessing data in an SDE publication (read-only) GDB. The external instance is behind a reverse proxy, so there is no firewall between AGS & SDE servers. We've deployed multiple viewers that use this base service and add other map services / layers on top of it.

The problem occurs on the external instance only and occurs intermittently (usually days apart) where the response time to redraw the base layer image takes an inordinate amount of time (several minutes, sometimes times out).

- We have isolated the "offending" layer to be our parcels layer which is actually a spatial view to merge table (same SDE GDB) based ownership attributes with the geometry FC. When this layer is deselected, base image returns to normal response time. (Again, this is intermittent & used in the internal instance without issue. So don't believe there's a fundamental issue with this method.)
- The other map services within the viewer will redraw within normal timeframes (while the underlying base image doesn't redraw timely) & affects multiple viewers using the base service.
- AGS Logs indicate a couple types of messages - "Internal Server Error. Wait time of the request to the service 'Public/AdamsCountyBasic.MapServer' has expired." and "Internal Server Error. Error handling service request : Processing request took longer than the usage timeout for service 'Public/AdamsCountyBasic.MapServer'."
- Fiddler does not report errors.
- Restarting the map services does not resolve the problem.
- Restarting AGS Services only provides temporary improvement is response time, then reverts to slow response for the base service image redraw(s).
- We've not been able to determine when and why performance returns to normal (found hours later).
- When the problem is occurring, we notice that the 'Instances in Use' does not  
- Increasing or decreasing the AGS Instances/Max Instances config doesn't appear to have an affect.

Common config:
- Both instances are VMs.

- The internal instance is AGS V10.0, external is V10.1.
- The internal instance is Windows 32-bit (awaiting upgrade), external is Windows 64-bit.

Note: We're aware of ESRI recommendations for cached map services, map optimization (which we done some), etc. But when the application isn't exhibiting this problem, the response time with our dynamic services is completely acceptable with both the internal and external instances. The fact that it usually performs quite well suggests there isn't an inherent problem with this approach.

So does anyone have suggestions as to next steps for troubleshooting this problem while its occurring?

Many thanks in advance!!!
0 Kudos
6 Replies
MVP Regular Contributor
Just to rule out the spatial view entirely, what is the draw-time performance if you add it to an empty map document and pan/zoom?  Is it always quick to draw or does it exhibit the same behavior as you see when it's intermittently slow in the external map service? 

For the external map service containing the spatial view, what are your timeout values set to (e.g., max time client can use service and max time client waits for a service)? 

Does the corresponding internal service match the external service exactly in terms of content (data layers, scale thresholds, symbology)? 

You started to say something about the instances in use within your post, but I think something got cut off because your comment seems to be incomplete.  Was there more information that you wanted to share on that topic?
0 Kudos
by Anonymous User
Not applicable

Q. Did you ever get to root cause of this?  We are suffering similar fate unfortunately on the same stack but in dynamic/feature services as opposed to basemaps.  esri Support yet unable to identify root cause.  We thought some of the issues were related to a config store on a remote (SAN) location but moving to local has achieved little.

0 Kudos
Esteemed Contributor

Are you having AGS performance issues with a layer such as parcels?  If so, have you tried to optimize scale dependencies on the layer's geometry as well as any labeling of the layer that you might have?

What version of AGS are you working with?

0 Kudos
by Anonymous User
Not applicable

Michael, thanks for the response BUT this is a much deeper issue than just a map rendering issue.  Its somewhere fundamental at the core of the product (or configuration) as opposed to responsiveness of an individual service.  We are on 10.1 in an HA architecture in a high performance environment (albeit complex). Our issues results in the services coming to a grinding halt after a period of time (days) with relative light usage.

0 Kudos
Esteemed Contributor

When you say an HA architecture are you referring to an Oracle SDE database using RAC?

AGS dynamic service performance has improved from 10.1 to 10.2 to 10.3, so you might want to consider upgrading to a more current version than 10.1.

0 Kudos
New Contributor II

Hi, I know this post has been a few years back already but did you happen to identify the root cause of the problem? Thanks.

0 Kudos