ArcGIS Server Performance: Behind the Curtain

So I am sitting in the audience watching another ESRI Demo on how the 9.3.1 AGS technology is so much faster than the 9.2. A couple of thoughts hit me right away. First, well that is a pretty low bar to get over; we all have heard the complaints from our clients. Second, of course they have the super duper Inline Server sitting 10 feet away from John Calkins running a demo that is optimized to show off performance improvement.  It made me wonder, well how big of a difference does Caching make, and for the vast majority of our client applications who require dynamic data, how well do the MSDs really improve performance on real map files.

We have started to quantify the performance gains in going from pure MXDs to optimized MSDs and finally to a fully cached map using the actual map files that are being deployed. Since we have been developing with the .NET ADF and the JavaScript and Flex APIs we have also been measuring the performance boosts with differing map service types with each of these technologies as well.

Some context for the types of map files we have been testing with. Our typical client map will have 15 to 25 layers, sometimes more, with a liberal use of scale dependent drawing. We typically view from a county level down to a parcel level view with our largest data layers being the local streets and parcel layers. The number of parcels we generally have for a county is between 35,000 and 100,000.

What we have seen our testing is for the .NET Adf applications an optimized MSD takes 1/3 the time to return a map to the user as an MXD.  We haven’t seen a significant different between the MSD and the Cached service. However, we have been able to measure the load on the server and while it takes the server half as long to process and MSD versus and MXD there is an additional 25% benefit when going to a Cached service. This could influence server sizing decisions depending on what kind of service you are able to deploy; you could support at least twice as many simultaneous map request using a Cached service versus an MSD service.

With the Flex and the JavaScript APIs we have seen an even more pronounced difference between the MXD and the MSD and Cache. An MSD and Cached service both respond about 20 times faster that an MXD.

Beyond the simple way you serve the maps to the application, the architecture and application code itself can be tuned to effect performance improvements.  We have seen significant speed improvements in initial loads of an application simply by architecting the first map to be a fully cached map (particularly useful with National or World Wide extents) and then switching to an MSD service as the user zooms in. 

While we don’t quite see the performance improvements across the board that ESRI was claiming from the podium, the 9.3.1 technology is definitely meeting and exceeding client expectations.

Additions to the GISi Team

GISi is proud to announce the addition of six new employees to the company: Todd Rowan, Ryan Kistler, Mike Haggarty, Neal Welbourne, Eric Polerecky, and Jim Moeller. Read more of this post

Welcome to Down to Earth

Aloha, ni hao, namaste, shalom and ¡hola! – or simply said, hello and a warm and respectful welcome to GISi’s new weblog.

I know what you’re thinking…” just what the world needs, another blog!”.   And you’re right, it seems like everyone has a blog or some type of social media channel they’re using to stand on a digital soapbox and share their thoughts with the world.   But the amazing thing about blogs (along with Twitter, Facebook, LinkedIn and other similar tools), is that it’s a big, big world out there.  And more noteworthy is that just like my welcome to you using different languages or cultural notions, the GIS world is very diverse.  Our industry includes analysts and programmers, project managers and administrators, executives and visionaries (which are not always synonymous!); there are people who use GIS in as many different workflows and markets as you or I could list.   The point?  At GISi we believe our talented employees likely have a point-of-view to share that will be of interest to someone, somewhere. Read more of this post

Dreaming on a Cloud

What I bring to the GISi team is a whole lot of scar tissue; the kind you only get from pushing technology beyond its design limits. The first wave of GIS began in the 1960’s driven by men like Roger Tomlinson, Howard Fisher and Jack Dangermond. They were the visionaries who understood computer technology could revolutionize the use of spatial data. These pioneers laid virtual graph paper across the world and transformed it into x.y coordinates. They conceived the data structures we take for granted: a road is a series of coordinates with intersections where it meets other roads.

In the 1970’s the nascent industry focused on building a technology toolkit to enter, maintain, display and analyze spatial data. This second wave was driven by government initiatives often implemented by technology entrepreneurs. The reliance on government funding was driven by the cost of hardware with mainframe computers selling for hundreds of thousands and minicomputers priced in the tens of thousands. Most GIS software was command line driven requiring a fairly sophisticated user base.

In the 1980’s the first commercial and widely used government GIS packages reached the market, beginning with Arc/Info®, GRASS, SPANS,  MapInfo®, Smallworld, MGE, and ERMapper. I was hired by ESRI in 1986 and eagerly joined this 3rd wave of GIS. Our mantra was “there’s definitely a practical application for this cool stuff” and we were determined to find it. We spent half our time evangelizing, convincing people that GIS really could solve their problems. We spent the other half reengineering the software tools to produce the benefits we had promised.

So you’ll have to excuse me if my posts sound like I’m dreaming on a cloud. It’s what I was trained to do; to look beyond today’s technology and what is currently “practical”. And I’ve spent my career transforming dreams to proven reality.