Enhancing ArcSDE Layer Display Speed
Continued...
Remind Me Why I Want This
After discussing some of the drawbacks, let's revisit the benefits of using sdegroup. The informal testing mentioned earlier took place at Esri's California regional office in Redlands, California, where the authors tested ArcSDE layers supplied by users. The layers ranged in size from 1 MB to 500 MB or from 2,000 to 800,000 records. Compared to drawing times for the original data, sdegroup layers typically drew 2.5 to 3 times faster at the full extent. At 50 percent of the full extent, sdegroup layers drew 8 to 10 times faster.
Many factors seemed to have no or little impact on these performance differences. For example, these same speed differences were observed both on high-powered and low-powered client machines and did not depend (very much) on the type of geometry (e.g., point, line, or polygon), although the complexity of the geometry (e.g., number of vertices) did seem to affect performance.
Imagine a map composition with three large layers. Say each layer takes 10 seconds to draw so that each map refresh takes 30 seconds. Using sdegroup on those layers could reduce drawing time for each layer to only three seconds, resulting in a total map refresh time of 10 seconds. At 50 percent of the full extent, this difference would be even greater.
Designing for Users
Every user wants faster drawing layers. However, supplying users with layers that have no attributes will confuse them. The key to using sdegroup is to design strategies that benefit end users without requiring them to know (too much) about the sdegroup layers.
An excellent place to start with sdegroup layers is the Internet. If you are using ArcSDE to serve data to the Internet through ArcIMS, you are already getting a big performance benefit. However, those full extent draws, which typically happen every time someone comes to the site and asks to see a map for the first time, can be slow. When authoring the map service, you can include both the sdegroup layer and the original ArcSDE layer and set the scale dependency such that the original layer draws only when it is fast and the sdegroup layer is used the rest of the time. Since the table of contents is dynamic (i.e., based on layer visibility), users will probably never know the difference—except that performance will improve.
There is always a chance that your users will try to identify a feature when viewing the layer at the full extent. Of course, identifying on the sdegroup layer will not return meaningful results. Fortunately, with ArcIMS, you can control the application so that when a user attempts to perform an identify on an sdegroup layer, you can do the spatial query programmatically and return results based on the original ArcSDE layer without having to draw the original layer. This is also true for attribute queries. Because ArcIMS is highly configurable and resides on your server, a little bit of application effort can result in a big performance gain.
Desktop GIS users are a more challenging case. ArcMap users typically add layers to maps themselves and directly control the map symbology, which means sdegroup layers will be a bit more of a burden to them. However, you can reduce the problem somewhat by using layer (.lyr) files. Layer files allow you to provide presymbolized data and multiple data layers (i.e., group layers) to users. Create a layer file that includes both the sdegroup layer and the original layer, and control the visibility of these layers at the appropriate scales.
Also, your desktop GIS users, more than Internet users, need layer attributes. While layer files allow them access to those attributes, it does change the users' experience slightly. With these users, your goal should be to get them to understand that sdegroup layers offer them a performance benefit. If they understand this, they will be more open to have minor changes in their work flow experience. That is probably the best-case scenario on the desktop.
Some Final Thoughts
The sdegroup utility offers opportunities to improve the performance of most GIS applications. While it cannot address all performance issues, the principle of data generalization offers lots of ways to improve your users' experience and get more out of your servers and networks.
|
