That's a great way to look at it. Same for me! HA Since this, we had a new development. One thing that was slowing us down with feature services was with some caching of domains. Sometimes that would time out, or take nearly 1 minute to resolve. Working a case with ESRI we found that just switching that rest call (just for queryDomains https://OURSERVER/WEBsrv/rest/services/LANDservice/LANDfeatures/FeatureServer/queryDomains) to forward over to the MapServer version - things worked fine. Fast, data and features were still coming through. But turned out - we had a user somehow load over 90k domain values on a single field in a feature class. Now that's one heck of a pick list! I say all of this to close out this particular thread with the knowledge (at least at my company) that 99.32641% of the time a performance problem has a data problem feeding it. Whether it be sharing shapefiles, bad mapped network drives in a virtual setting, super large publish/copy fGDB to hosted services, or bad rules like 90k domain values, you can fix the data, fix the problem. We have to be very wholistic in our approach when we get complaints like "ArcGIS Pro has been sluggish all day, and others on my team are saying the same thing". Usually ends up not being Pro at all so if you clear that old cache, and still have major headaches, start looking into your data.
Not everyone can go to ESRI for a case, and yes here - we were looking at domains and completely missed 90k on a single FCs field for some 6 months with a work around. Finally our DB crashed with a patch and we found multiple issues once we fixed this data problem. We're humming well right now, so well we are thinking of upgrading to 11.1. May as well start over again! 🙂
The slow queryDomain return was found because of the Diagnostic Monitor Ctrl-Alt-M.
Thanks for commenting!