Hello,
I have a custom print service that can often run so slowly that we receive timeouts at intervals greater than 5 minutes. Understanding that there are a great many factors that influence job run times, here is a common print setup, which experiences a timeout.
9 layers, some of which do not have features in the print extent, displayed over an aerial image (a cached map service referencing a locally stored image), at 300dpi.
The print service is synchronous, returning up to 1000 records, dedicated with 2 min and 2 max instances. The print templates have the map frame, a legend, a couple pieces of dynamic text, and a locator map. I've tested out with removing the locator map but that is at best a marginal improvement. Ditto for using a vector tile basemap as opposed to the aerial image. Finally, I have gone through some general remove-one-layer-at-a-time type testing, and there are many occasions where anything more than a single layer will cause extremely long print times. The map this print service runs against has a couple hundred layers, though most of the time only a small subset are toggled on.
The general setup is institutionalized to the point where I don't have much experience doing anything else. My hunch here is that it is a tangled web of complex symbols, the underlying aerial, and something about the configuration of the service that I just don't know enough about.
Any advice or troubleshooting steps I'm missing would be great!
One thing to try is testing out the installed esri print service and see if it runs normal. That could help troubleshoot whether its your custom service or not.
Another thing to check is the server manager for the service and try experimenting with the execution mode to see if either setting helps.
Zach:
Have you ever tried putting the print service into Asynchronous Execution mode as mentioned above by Jon?
Have you tested the print service in an app only used by yourself and seen the same issue? Maybe if it is a public facing app, many users are trying to print at the same time.
Is the print service always slow or just certain times of thee day?
I'm going to give the built-in service a shot but unfortunately for this specific map (the framework of which is managed by a consultant), the mode must be asynchronous. That consultant ownership is another wrinkle of course, but I figure I oughta test as much as I can under my control.
Have you tried testing the ExportMap operation on each individual service to see if one of them is especially slow?
do you see the same performance issue if you try with the default print service that comes with server install with one of those default templates?
@TanuHoque and @JonM32 , the built-in print service does give me the same behavior. I've got a lot of variables here, so I'm going to keep a spreadsheet going on each of the tests. The third-party application is called DataFi, and we have a prod and dev skeleton that I'm using.
Looking at a set of initial 10 tests here, it appears at first glance the most consistent thing is the data itself. I've tested in Map Viewer as well, and the behavior is mostly reproducible there. Interestingly, we have situations where identical variables produce differing results. I think that might be a result of other users doing their own printing, so my request has to wait a bit to get an instance, then actually run the print. But that's a guess.
I'm going to keep up the testing and tweaking the inputs and I'll return with more updates unless someone sees something obvious that I'm missing.
Edit to ask: generally speaking, what types of symbols might slow down the print service? PNGs? SVGs? I have a few services that use PNG image symbols and others that are either SVGs or stacked symbol layers.
Hello, have you tried changing the print service to a dedicated instance?
It currently is dedicated, 2 max/2 min. I will probably up the instances to 4/4 or something like that.
An update: I upped the number of instances for the print service and it seemed to me to make a difference, but my users questioned how many people were actually printing at one time, like they wouldn't have expected to run into timeouts due to availability. Could be they underestimate the number of printers (after all, only 1 or 2 people ahead could cause a big slow down). I've asked them to notify me when they run prints so we'll see if they experience anything different. I'll keep this post marked as un-solved for now, but this might be a decent fix.