Extremely Poor Performance Using the JavaScript API and a WebMap

4660
14
11-22-2017 08:06 AM
MichaelHamsa
Occasional Contributor

Hello,

We have developed a web site that is using the ArcGIS JavaScript 4.3 API and we're noticing some extremely poor performance with the map drawing while using a WebMap loaded with a portal item ID. The map has 1 layer in it with about 900,000 point features. The visibility of the layer is set to Neighborhood so it does not come on until a pretty low zoom level.

It is very common to zoom into a small area of the map on our site and never see the features drawn (the base map is drawn), or to only see a handful of the features when we know there are a lot more in that area. I've even done some tests with the ArcGIS API for JavaScript Sandbox by loading the a WebMap with the same portal item's ID and I see the same issues with performance - I can zoom into an area where I know the features should be drawn and I never see any - never. In contrast, when we log into our ArcGIS Online Portal and open the same web map it seems to draw very quickly. 

So it seems to be a problem with the JavaScript API.

We've tried it on a number of different computers, with different browsers, in different locations on different networks and the same performance issues are seen.

What can we do about this issue? Has anyone else seen this problem? Is there some trick to use to get good performance using the JavaScript API WebMap?

Thanks in advance,

Mike...

0 Kudos
14 Replies
MichaelVolz
Esteemed Contributor

Are you seeing no features or do you think you are seeing about 1,000 features but that is a much lower number of features than you expect?  1,000 features is the default by ESRI so you don't have performance issues with too many features getting rendered.

MichaelHamsa
Occasional Contributor

Michael,

It really varies. Sometimes you zoom into an area and you don't see anything - no features at all. Other times you may see 10 features or 100 features. If you leave the map up for 30 minutes (as an example) the features slowly start to appear. And 30 minutes isn't an exaggeration. It can a long time to see any features.

But like I said, in contrast with the ArcGIS Online Portal - viewing the same map - it draws very quickly.

Here's an example - here's a screen shot from the ArcGIS API for JavaScript Sandbox loading the map with the portal item's ID - this has been sitting for about 10 minutes. Notice no features - only the base map. I'll let this sit for 20 or 30 more minutes and the features will slowly start to draw.

Here's the same map, in the same area but using the ArcGIS Online Portal map instead. This map rendered all of the features immediately.

I don't know?

mike...

0 Kudos
MichaelHamsa
Occasional Contributor

Here's another shot of the ArcGIS for JavaScript Sandbox map after it has been sitting for about 10 minutes. Notice the features are starting to be displayed along the left side of the map. But only a 100 or so of them - this is after 10 minutes.

0 Kudos
AndyGup
Esri Regular Contributor

Hi Mike, I recommend starting with the browser's developer tools and taking a look around:

- What browser and version are you using?

- Are there any error messages in the console?

- In the network tab how long do the feature service query(s) take and how much data is being returned?

- Have you tried running the same code in jsbin or on your local web server?

- Do you see the same behavior when running this sample app?

I also checked the ArcGIS Online Health Dashboard, and it's all green.

This info will help to start narrowing things down.

MichaelHamsa
Occasional Contributor

Andy,

Thanks for the response.

Right now I'm doing all of this testing with the ArcGIS API for JavaScript Sandbox - but we see the same behavior using the JavaScript API in our own web site. I just wanted to make sure it wasn't anything we were doing, or how we are hosting our web site - so seeing it the ArcGIS API for JavaScript Sandbox has confirmed that.

The sandbox we're using; just plugged in the portal ID for our web map and we can reproduce the problem:

https://developers.arcgis.com/javascript/latest/sample-code/sandbox/index.html?sample=webmap-basic

We are seeing it in all browsers - I can reproduce it at will in Edge, IE11, Firefox and Chrome - on the same machine and on different machines. We've had users testing in other cities and they see the same thing consistently - they are mainly running IE11, but they have tried it with Chrome as well (the only other browser they have access to). We've tried inside and outside our network - same issue.

There are some errors in the console, but they don't tell us much:

[esri.views.2d.layers.MapImageLayerView2D] [ondemandcontroller2d:tile-request-failed]: Failed to query for features

Dig in a little, and you see "Timeout exceeded" querying our online feature layer (URL) - so I'm assuming that the requests are just taking too long.

Network Tab: There are hundreds of requests. The longest running request I see was 74 seconds.

JSBIN Question: We're seeing it in the Sandbox and in our web site - so we'd likely have the same issues with JSBIN.

The Sample App you provided runs great; however it isn't using our web map or the feature layers (obviously)

I looked at the Online Status yesterday - just to check - and everything looked good then as well.

Mike...

0 Kudos
MichaelHamsa
Occasional Contributor

Andy,

Most of the requests fail due to timeout issues. One of the other things I'm seeing in the response headers from these requests:

server: AmazonS3

x-cache: "Error from cloudfront"

Thanks again,

Mike...

0 Kudos
AndyGup
Esri Regular Contributor

>>Network Tab: There are hundreds of requests. The longest running request I see was 74 seconds.

Hmmm, that doesn't sound right and it may be the source of your problems. What types of requests are these, are they queries?

Can you provide the following from several of those requests:

1) Query String Parameters (Network Tab > click on request > Header), for example:

f:json
where:1=1
returnGeometry:true
spatialRel:esriSpatialRelIntersects
outFields:*
outSR:102100
resultOffset:0
resultRecordCount:2000

2) A count of how many features are being returned from each request (Network Tab > click on request > Preview)

0 Kudos
MichaelHamsa
Occasional Contributor

Thanks Andy.

We're just zooming around on the map - they are query requests from what I can see. Here's one of the requests (I replaced the actual layer name with "OurFeatureLayerName").

https://services.arcgis.com/eP8V7tJrYd6ZUBkc/arcgis/rest/services/OurFeatureLayerName/FeatureServer/...

1) Here are the query string parameters:

   f: json
   geometry: %7B%22xmin%22%3A-9223809.077229367%2C%22ymin%22%3A4852834.051770989%2C%22xmax%22%3A-9222586.084776805%2C%22ymax%22%3A4854057.044223552%2C%22spatialReference%22%3A%7B%22latestWkid%22%3A3857%2C%22wkid%22%3A102100%7D%7D
   geometryType: esriGeometryEnvelope
   inSR: 102100
   outFields: *
   outSR: 102100
   returnGeometry: true
   spatialRel: esriSpatialRelIntersects
   where: 1%3D1

2) I took a look at a response from of the requests that succeeded and it looks like there were 83 features.

Here's a request that failed - it ran for 103.9 seconds and it does not have a response body:

https://services.arcgis.com/eP8V7tJrYd6ZUBkc/arcgis/rest/services/OurFeatureLayerName/FeatureServer/...

Here are the response headers for this request - notice the "Miss from cloudfront" in the x-cache header:

   access-control-allow-origin: *
   cache-control: public, max-age=0, s-maxage=0
   content-type: text/plain; charset=utf-8
   date: Wed, 22 Nov 2017 20:46:25 GMT
   etag: sd304_-148574809
   last-modified: Wed, 22 Nov 2017 14:47:48 GMT
   request-context: appId=cid-v1:f95092ba-7fdd-4452-a0e3-c1cfdc4250e2
   server: Microsoft-IIS/8.5
   via: 1.1 e9b460d4fbe79e1b34e06840ef460c69.cloudfront.net (CloudFront)
   x-amz-cf-id: H-tXg_YB16glnrANqEGCKjE5SD-QUPaeFNVwAsbBHSD9QCIj6hPouA==
   x-arcgis-instance: MTSDS_Web_IN_33
   x-cache: Miss from cloudfront
   x-powered-by: ASP.NET

Or I get a response with headers like this - noticed the "Error from cloudfront" in the x-cache header. This request ran for 180.05 seconds. Again, it does not have a response body.

   accept-ranges: bytes
   access-control-allow-methods: GET
   access-control-allow-origin: *
   access-control-max-age: 300
   age: 23
   content-length: 75
   content-type: text/plain
   date: Sun, 12 Nov 2017 20:06:46 GMT
   etag: "e2651e71c06f4a6d095cb118ebfc79e2"
   last-modified: Wed, 28 Jun 2017 00:39:39 GMT
   server: AmazonS3
   via: 1.1 e9b460d4fbe79e1b34e06840ef460c69.cloudfront.net (CloudFront)
   x-amz-cf-id: xwGkF7ZwzhL61SL5AZWFKvI6fGFMghwBkyEpTII4GFKslWBXSSWwJg==
   x-cache: Error from cloudfront
0 Kudos
AndyGup
Esri Regular Contributor

>>We're just zooming around on the map

Have you tried configuring clustering? Clustering in ArcGIS Online Enables Data Exploration (September 2017) | ArcGIS Blog. And did it help?  [Edit: disregard this suggestion - it may not work on your dataset given the total number of features]

Can you run a single query request from your browser to see if that works okay? For example use the one from above that took 103.9 seconds.

You might also try adding that feature layer to a plain old ArcGIS API for JavaScript app and see if you get the same issues? Example

0 Kudos