Best Practices for Speed
HI All,
Anyone have any tips on improving overall performance? reduce load times, reduce panning times, reduce identify times etc?\
Best practices tips list?
Ken
-
In practice it seems that one of the biggest single things you can do to improve the speed of your maps is to break single monolithic ArcGIS Server mapservices into many smaller mapservices so that they can be more efficiently served. This can have an immediate and dramatic effect on speed and stability, and Essentials allows you to easily combine multiple mapservices so that there will be no other discernable difference to the end user.
It is also a good idea to read and follow the suggestions produced by ArcMap when converting your MXD to a MSD in preparation for serving. However, most of these things will have very little effect compared to the above, and it is fine to ignore 'warnings' if doing so makes for a better map in your opinion.
0 -
Thx Jonathan...
I've also tried,
1) Turning off as many features as possible...ie "allow identify","show legend", "show map tips" for each layer
2) Reducing the number of layers in the table of contents.
3) creating smaller number of map services instead of one giant map service
4) Using PNG8 instead of PNG32 where possible (Not sure if this helps but if my map service is cached, I try to match the map service format with the display setting in Geocortex)
How about Indexing your datalinked fields and spatial indexing your map services?
Please feel free to add to list anyone.
0 -
I concur with Jonathon and Kenneth's tips here....
keeping the site.xml file trim as best as possible is a good way to start.. although it can be hard to balance form over functionality at times. We have 2 sites for example: one is a 'viewer' of sorts that has less map services, less tools, so less XAP files to load etc, while our other site has all the trimming including custom tools. There is a marked difference in load times. You can track the speed of loading with something like fiddler and or firebug. You get some interesting results. Once the sites are cached in the browser things swim along much faster of course.
I also found that adding 'field' items in the rest manager loaded up the site file enormously - so I've avoided this and done all the field hide-show in the mxd/msd..
But obviously some commons sense prevails in tuning your map services as best you can. Caching map services etc. does help a great deal with speed, albeit at the expense of good quality map prints. But as mentioned it's a balancing act. Pack light and then go from there ; )
cheers
Gareth
0 -
Ah...good point Gareth about the reducing the fields in the map services.
Also, I wonder if there were any compression techniques applied to the xml files? compressing the xml files should speed up loading times as well....(Am I opening up a can of worms LG?)
0 -
Reducing the physical size of the configuration files won't have a huge impact on performance, as these are only loaded once for a viewer session (and hopefully cached for future sessions). We usually also try to enable wire-level compression on our content so that it will be sent to the browser compressed (if the browser requests it).
It's best to work on optimizing the things that normal users do all the time - map draws, report generation, etc. Removing tools and modules that you are not using will probably help a little, but optimizing mapservices in ArcMap and ArcGIS Server will have a far greater effect, and not just on initial load times. The speed bottleneck on sites is almost always due to mapservice intialization and subsequent image generation, so work in this area should pay off with noticeable improvements.
0 -
Jonathan,
How does one combine the map services in Essentials, so they don't look like lots of smaller services to the end user? I couldn't find anything in the help. I tried giving two services the same display name but the name just shows up twice on the layer list. We currently have 14 dynamic services in the site and I wouldn't want to visibly increase that any.
We're using GE 3.7 and a viewer based on the Sample Flex Viewer.
Thanks,
Martha
0 -
I would hide the mapservice entry (if you are really concerned that they look like the same mapservice) and just show the layer names in the layer list. 14 dynamic services sounds like you have already split things up quite a bit though -- there is a limit to how far you can go with this and expect to see a performance improvement.
If you are using the Flex viewer, you will also have to write the code to respect your mapservice / layer visibility settings, as I don't think that this capability is in there by default.
0 -
Jonathan,
Slightly deviating from original topic but building on comments w.r.t. structuring your map services.
Fundamentally we are constrained by the geocortex TOC design such that there is not concept to group a set of layers other than that @ the mxd level which leads to the evolution of 'large' published services (originating @ the mxd level). A current shortcoming of the product is that is does not support the concept of a group (or folder as in ADF clients) other than that offered by Themes. Themes unfortunately is only as good as the map services it can consume. I know I know we don't talk TOC's these days in the modern web map (some of just can't let go of it) but its fundamental to structuring your data for a core viewer application.
Are you able to indicate if this is being considered as a product enhancement in future releases? If so are you able to indicate what its priority is & any indication we can likely expect this functionality?
Let me know if I'm missing a trick here.
Regards
Brad
0 -
Thanks, Jonathan,
I was afraid I was looking for something that wasn't there.
I'm with Brad on this one. We've got close to 200 layers in our application (including the groups of scale-dependent symbology for a single layer). Every one of those layers is there because it was requested by a team.
For ease of access, we've organized the layers in services as our ADF applications presented them. This creates two major trade-offs: organizing the layers in point, line, polygon order means they can't be presented in alphabetical order to the end user and labels from one service happily overwrite labels from another. We've done our best to cheat the MXDs a little so shapes aren't likely to be overlaid and hidden.
Turning off the service names would make it impossible to find anything without using the filtering tool. Even though we've given people the capability of creating and saving their task-specific layer combinations, they want it to be easy to find what they're looking for on the layer list.
To attack the other problem,we're thinking of creating a new service of labels only that we'd put on top of the stack so they could be toggled and wouldn't overwrite each other. Adding yet another service, however, would increase the load time even more.
Bottom line is that some interface that separates the physical organization from the logical presentation would be a tremendous boon.
Thanks,
Martha
0 -
Having the abilty to control layer order vs drawing order was an enhancement request mentioned in one of the forums.
A minor work around is to rename your layers differently so they are alphabetic. for example...Buildings can also be called "Structures", Sewers can be called " Utilities - Sewer" etc.
Basically, you are renaming the layers to fit alphabetically in the TOC.
0 -
Having more control over layer organization and presentation at the Site level is a feature that is currently being considered for development. We don't yet have a firm timeline/release commitment for this work. We'll try to keep the group updated on this.
I hope this helps,
Dave
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
11 Kommentare