nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cache slow in mashup

KeithSandell

My cached maps render instantaneously in the REST javascript viewer as well when they are in a very simple application.

In the below described app the cached maps can take up to 50 seconds to render, and in some cases I receive Error 500 Internal Server Error messages and missing tiles. FF and Chrome indicate that the app is waiting for the server.

The application I am seeing performance problems with has a total of:

4 cached base maps
5 graphics layers
9 cached operational layers (these are the slow ones I mention above)
3 dynamic maps
21 featureLayers (MODE_SELECTION)
and just to be complete
6 geoprocessing tasks
1 locator
1 identify task

So I have a total of 42 mapLayers.

I'm not sure if this qualifies as being a lot of layers in an app, and if it may be part of the problem.

Any thoughts out there?

Thanks

Encontre mais publicações marcadas com

Accepted answers

All comments

KeithSandell

Nope, don't see a performance problem if I comment out beginBuildApp(), well because that prevents the app content from being built.

I did however find what appears to be the problem.

A note before proceeding; All of the layer in all of the map services that are accessed for this application are Query Layers using SQL Spatial Types. Not sure if this has something to do with it. I haven't tried this with Feature Classes.

In watching the App Server processor utilization and the number of instances of services that were being spun up to deal with a request got me thinking.

After the app is built in the browser and the server processor utilization has dropped to 0%...

If I turned "1" locally cached layer on (my data) the app server would peg out to 100% and the service would spin up 5 instances and use 5 instances to serve out 28 images.

That seems a little excessive. So I limited the number of instances a service can spin up to "1".

Minimum 1 and maximum 1. - I had to do this on all services that are used by the application.

And now the app runs like a finely oiled sewing machine.

But doesn't this affect the scalability of the application?

derekswingley1

Do you see the same performance problem if you don't call beginBuildApp()? Can you comment it out and let us know how that affects performance?

Also, the Net and Network tabs for Firebug and the Chrome dev tools have subsections. Any chance you're only looking at the "Images" section and not the "All" section? You should be seeing quite a few more requests just to load the various pieces of the JS API plus the six additional scripts you append to your page once all the map code runs.

KeithSandell

I'm not sure if 10 seconds is really a flag considering when the app is loaded it has to dynamically build 19 unique lists, of which it does consecutively. One query, one build; One query, one build and so on. I used to throw all of the requests at the server at the same time, but it didn't like that.

The lists are generated from tables with only the absolute necessary columns to support their creation. As well, all other layers in the application only expose the bare minimum columns.

The important part of the code is attached with server names commented out. To build the application alone it takes a little over 1,200 lines minus some whitespace and a few comments.

Add the html and we have 2,000 lines and the rest of the functional javascript and we are up to about 5,000 lines.

Anything that is not needed to build the app is left to load after after the mapLayers have been added.

I have tested the same cached map layers in a simple basemap only application and the performance is on par with the REST javascript viewer.

It just doesn't seem to make sense that if the only thing the browser is doing, or at least what it is reporting under the NET or Network tabs of the dev kits is fetching 28 tiles, the performance I would think in theory should be the same regardless of what app the cached layers are in.

And another note the featureLayers that expose the geometry render their geometry almost instantly in a dynamic state.

code.zip

derekswingley1

Opening the application only takes about 10 seconds.

I would say that's a red flag. 10 seconds is an eternity for a web app. I think you should be shooting for 1, 2 seconds top to load your app.

I do load all the layers in stages or consecutively, one after another so as not to request to much of the server at once, and this works pretty well.

Can you post your code to show how you're doing this?

The performance issue that I see is not when the application loads, but after the app is rendered and ready for use...when one of the locally cached functional layers/maps is turned on it pegs out the server and in many cases does not return all of the tiles.

I've watched the network utilization in Chrome and FF and when the request is made to GET the cached images the only network traffic that is shown is the GET requests for the tiles, 28 requests for 256x256 tiles.

If you put your cached map in one of the simpler samples, do you see the same performance issue?

KeithSandell

There are 42 layers available in the application, by default one 1 is turned on.

All of the layers except the base map have definition expressions set, or have their visibility set to false, or use imageParamters to hide features, before they are added to the map so the only thing that is displayed initially is the basemap.

With only the basemap being displayed, if the local cache is turned on, 28 images to GET, the server pegs out.

????

HemingZhu

Yes, that is a lot of layers. You're comparing the load time of 42 to layers with that of one when you compare your app to the JS preview from the services directory. It's kind of like saying "Firefox opens immediately when I open it with one tab but if I open it with 42 tabs it takes forever".

You're probably overwhelming your server. Do you really need 42 layers in your web app? Can you combine any of your services? What about loading services at run-time instead of when your app starts?

In cartography, there is a thumb rule that don't show > 5,6 colors. It overwhelms your eyes let alone show these many layers(at lest for showing map purpose). Maybe you could set up visible scale or toggle visibility so that at certain scale you could constrain the no. of showing layers.

KeithSandell

Opening the application only takes about 10 seconds. I do load all the layers in stages or consecutively, one after another so as not to request to much of the server at once, and this works pretty well.

The 42 layers are required. They are disparate types of boundaries and features that all have different attribute tables so they cannot be combined, and of which the users have a need to use in varying combinations so they need them all, but also need them all separately; business requirements...gotta love 'em.

The performance issue that I see is not when the application loads, but after the app is rendered and ready for use...when one of the locally cached functional layers/maps is turned on it pegs out the server and in many cases does not return all of the tiles.

I've watched the network utilization in Chrome and FF and when the request is made to GET the cached images the only network traffic that is shown is the GET requests for the tiles, 28 requests for 256x256 tiles.

Yet it chokes on it.

derekswingley1

...I have a total of 42 mapLayers.

I'm not sure if this qualifies as being a lot of layers in an app, and if it may be part of the problem.

Any thoughts out there?

Yes, that is a lot of layers. You're comparing the load time of 42 to layers with that of one when you compare your app to the JS preview from the services directory. It's kind of like saying "Firefox opens immediately when I open it with one tab but if I open it with 42 tabs it takes forever".

You're probably overwhelming your server. Do you really need 42 layers in your web app? Can you combine any of your services? What about loading services at run-time instead of when your app starts?

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.