NEARC-L,

Thank you to Tom Schwartzman for asking his colleagues about this topic on my behalf, and for summarizing their answers for me. The answers to my two original questions are:

1.      Is it correct that the ArcGIS API for JavaScript allows the developer to make a single, spatially-filtered request for a feature set, and generates from that multiple REST API requests covering the area-of-interest?

Yes.

One respondent indicated that this only occurs when requesting data "through the map view", but that if you "make a direct single querytask query" that the JavaScript API should yield one request to ArcGIS for Server. (Note that I quoted specific phrases above because I don't know enough about the JavaScript API to provide supporting context; I suspect that developers in the audience will know what the "map view" and "querytask" are.)



2.      If so, why? (Stated another way, why not just make one REST API request, like with PNG files?)

There are two primary reasons:

*       Requesting a smaller subset of features per operation avoids exceeding the maximum number of records that the service will return per-query (maxRecordCount). If you are viewing a large area, you can end up asking for a lot of features. So, the JavaScript API automatically queries smaller regions, and asks for multiple such regions to cover large map extents.

*       Asking for multiple, smaller requests improves performance because:

o       The "tile" extents are fixed, and the query results are cacheable. So, if you pan/zoom/refresh an area that you've recently viewed - in whole or in part - the requests for the same "tile" will be the same, and you can potentially read the results from cache, rather than going back to the server. (I interpret "cache" here to mean the browser cache, but it probably applies to web accelerator/caching devices, too.)

o       Each response is smaller (though we didn't get into the details as to why multiple small requests are faster than a single large one).

I have several follow-up questions (e.g. how are the "query tile" boundaries determined; how are records that cross into multiple tiles handled, etc.) so if anyone has additional information and would like to continue the discussion, please call or write. But, this covers my immediate issue at-hand, so I'm going to turn my attention back to the server-side issue that initially brought this client-side behavior to light.

Thanks again to Tom and his colleagues!

-Michael

P.S. I'm responding from Outlook 2016 using "Rich Text" instead of "HTML" this time to see if the formatting is preserved once the listserv distributes the message. May apologize if it comes out as plain text again. -M


Michael Mannion
Database Consultant | Mannion Geosystems | +1 617.939.9958 | http://www.manniongeo.com<http://www.manniongeo.com/>


From: Michael Mannion
Sent: Wednesday, August 24, 2016 4:07 PM
To: Northeast Arc Users Group ([log in to unmask]) <[log in to unmask]>
Subject: Multiple requests for Query operation

NEARC-L,

I'm working in an environment that includes a custom web app that uses a variety of ArcGIS for Server map services, and I'd like your help in explaining some behavior that I don't understand.

I'll preface the information below by stating that I'm not a web developer, and this app isn't my area of responsibility. But, the app's behavior manifests some back-end issues that are in my AOR, so I'm trying to understand the larger environment in hopes of diagnosing the server-side problems. The takeaway is: If anything I say below seems incorrect, you're probably right and I'm probably wrong, so please correct me or ask a follow-up question.

The salient contextual points are:

*       From what I understand, the app interacts with ArcGIS for Server using the ArcGIS API for JavaScript. I don't know what version of the API it's using, but the app was built within the past two years, if that's any indication.

*       The map services are provided by a cluster of ArcGIS for Server 10.3.1 instances.

*       From watching the network traffic using Chrome Developer Tools (CDT), the app appears to ask for data in one of two ways:

o       As a map image resource in PNG format, via the Export Map operation, or;

o       As a feature set in JSON format, via the Query operation

Per this last point, I don't know what this implies is happening at the JavaScript API level, but those are the underlying REST API requests that I see in CDT.


The interesting part is:

*       For any one pan/zoom action on the end user's part:

o       There is a single Export Map request for a PNG that covers the whole map extent, but;

o       There are multiple Query requests for the feature sets, each of which covers only a portion of the map extent

The following screenshot illustrates this behavior:



The number of Query requests varies. In the screenshot above, there are 12. I usually see 9, but sometimes 4, 6, or 8. This happens at all scales (that I've noticed, in my unscientific poking-and-prodding).

If I extract the extent of each one of those Query requests from their respective URLs and draw them as graphics in ArcMap, I see a pattern that looks like the screenshot below. Note that the screenshot below (9 requests) doesn't go with the screenshot above (12 requests), but it illustrates the general behavior:



In this map, each of the 9 boxes represents the extent of one Query operation. The requests are sent in order like you're reading a book (left-to-right, top-to-bottom). My actual map extent fell within, and was slightly smaller than, the area covered by these requests.


The lead app developer confirmed that they aren't explicitly querying data in this "tiled" pattern; rather, that the multi-request / tiled behavior is built in to the JavaScript API.

My questions are:

1.      Is it correct that the ArcGIS API for JavaScript allows the developer to make a single, spatially-filtered request for a feature set, and generates from that multiple REST API requests covering the area-of-interest?

2.      If so, why? (Stated another way, why not just make one REST API request, like with PNG files?)

Beyond simple curiosity, there is a practical consequence of this behavior - some of the Query requests either 1) take a long time, or 2) fail. (That's the server-side issue I'm investigating.)

The impact on the end user is that the first row of "tiles" may display data immediately, while the second row could take 30 seconds, and the third row might fail to return data at all. There are no "still working" or "error" type messages in the UI (an app issue, or an API issue?), so the user may think that data only exists in the northernmost part of the map extent and draw the wrong conclusion.

If you have any insight into this behavior that you're willing to share, I'd be much obliged. Thank you, in advance.

-Michael


Michael Mannion
Database Consultant | Mannion Geosystems | +1 617.939.9958 | http://www.manniongeo.com<http://www.manniongeo.com/>



------------------------------------------------------------------------- This list (NEARC-L) is an unmoderated discussion list for all NEARC Users.

If you no longer wish to receive e-mail from this list, you can remove yourself by going to http://s.uconn.edu/nearcsubscribe.