Using ArGIS Desktop’s Map Service Publishing Toolbar
May 14, 2009 15 Comments
One of the best new features of ArcGIS 9.3.1 is the Map Service Publishing toolbar in ArcMap. This tool helps you analyze your maps to see what is slowing the map down. No longer are you having to look for the needle in the haystack. You just activate the toolbar and hit analyze. Then ArcMap returns all the errors and warnings associated with your mxd.
The new Map Service Publishing toolbar in action.
If you double click on any of the “issues” it will take you to documentation explaining the problem and how to fix it.
ArcGIS Server documentation helps figure out how to fix problems.
One other feature about the toolbar which is a big help is the preview. You can preview any map on how it would be served in ArcGIS Server, from right inside ArcMap. You also get a timer to show how long it took to generate that request. This is of course helpful for the ArcGIS Server services, but can even be used to speed up ArcMap documents that are only going to be consumed on the desktop. If you’ve been working with a mxd that seems to be loading slowly, now you have the tools you need to debug why the map isn’t performing quickly enough.
The Preview ArcGIS Server window allows users to determine the speed at which their maps are rendering.
The toolbar also allows you to generate the Map Service Definition (.msd) files and even publish directly to ArcGIS Server from ArcMap (bypassing the need to go to ArcCatalog or the web manager).
The Map Service Publishing toolbar is really a great addition to the ESRI workflows, both Desktop and Server. Looking back at some of our existing map services we had authored with ArcGIS Server, I was amazed at how easy it was to discover the problems and then address them. Coupled with the new MSD files, ArcGIS Server is really a speed demon these days.
About James Fee
Most excellent!!
James, do you see yourself using the newer format service more? Or do you think that the features such as Maplex that are not supported in the new format will keep you in a MXD Service?
I am seeing that there is still the benifit to the MXD, then building a really nice base layer, then sticking business services over the top with the MSD.
Anybody else have recent revelations there?
David, I’m not sure the benefits of Maplex out weigh the speed penalty. In my experience, speed of rendering is all that matters. Of course you could just make a tile cache out of them and maybe that is the best method for “rich” cartography.
MSD’s improve performance so much that I just can’t see using MXDs anymore unless there is a REALLY important reason.
yeah, like web editing.
In my experience with ArcGIS server speed has been an issue that can only really be overcome by caching. This looks like it could be another option that avoids you having to create millions of cache files. The workflow looks so much better as well. Looking forward to trying this out.
Glimmers of hope – this is good stuff.
Render speed is the #1 determinant of end-user smiles.
Due to the MSD speed enhancements I installed 9.3.1 as soon as humanly possible. Our dynamic map services that pull locally from SDE 9.3 are starting up in half the time with a fully tailored MSD. In general, the services running from an MXD at 9.3 loaded in approximately 25-30 seconds on our local intranet, which was intolerably slow. After initial load in IE 7, the refresh time would drop to ~19 seconds. The equivalent MSDs (no Maplex) after completely “clearing” the MXD of potential errors load at around 9 seconds at initial startup and 5-6 seconds on refresh. The overall performance once loaded is also much faster. In fact, we’re likely to dump our separate cached services since the inability to turn off layers is a massive inconvenience for many of our users. However, they work great for public consumption.
Overall, great work by ESRI to help optimize the dynamic services. Consider us pleased customers.
Cheers,
-Matt
I have been pretty happy with the MSP performance. I guess we will have to play more with the options for using standard text for our labeling versus maplex.
Having to do a lot of dynamic display for a entire state down to the street level with a google’ish style of cartography might be interesting to see.
~D~
One of the cooler things I’ve found about this toolbar, is that if you do not click save as msd and only click publish, ArcMap will save an msd to an arcgisinput folder and keep them organized for you…
Matt, would be interested in knowing what items the analyze tool found in your mxd that resulted in the improvement in load and refresh times.
This may be common knowledge but maybe there are others like banging their head against the wall about this.
If you are doing any kind of fine grained ArcObjects you need to stick w/ the MXD rather than the MSD.
It makes sense when you think about it but I lost an hour because I wasn’t thinking about it
We have been experimenting with caching. There are clearly good situations were caching is needed. However, I’m not really a fan. It’s not flexible enough, and a 200MB layer could end up being 4 Gigs when cached. You can’t cache layers that require editing as this produces really funky results. Caching forces any usage into specific scales if you want it to look decent and let’s not even talk about two caches designed at different scales. Also caches can rarely be used cross-application because requirements are always so different.
I favor using file geodatabases replicated local to the server. We’ve been able to produce cache-like performance using this method; even using maplex. Another thing we’ve done is to attach massive amounts of SAN storage to the server so it looks like a local disk. Why is local disk so important? So the MXD can access it via drive liver Vs. UNC path. You’ll take a huge performance hit when using UNC. The down side to this is that you must have ArcMap installed on the server and open the MXD from the server and repoint the layer sources (anyone have a solution for that one?)
Summary of our options:
—Native SDE data
—Replicated FileGDB (local to server)
—Replicated FileGDB (SAN storage)
—Replicated FileGDB (NAS storage)
—Cached layers
The difference between SAN and NAS storage is basically performance Vs. $$$. NAS is a but slower but much less expensive so you can get more of it. For instance we have about 25 terrabytes of imagery. That’s a wee bit cost prohibitive on SAN
something that is an even bigger deal than this toolbar are the new licensing terms. At 9.3.1 advanced, you get all the analysis extensions (except for interop). Also, you can now install the web adf runtime and SOM on as many boxes as you want, you only license the SOC now.
Pingback: James Fee GIS Blog » Blog Archive » The ESRI 2009 UC Plenary
Great post. Thanks fir sharing it. Its is really interesting and informative.