Why would programmatically setting the extent of a map on Page_PreRender be really slow?

Question

We are using the ArcGIS 10 web adf with C# in a web application. We just recently upgraded everything from 9.3 to 10 and moved all the hosted stuff over to a new (more powerful) server. Still on the same network.

During the Page_PreRender event, we get the full extent envelope of our map, which is fast, and then set our map's extent to it.

Code in question...

Envelope fullExtent = AgsHelper.GetExtent(Map1, ExtentType.Map);
Map1.Extent = fullExtent;

The second line there takes a really long time (like 30-40 seconds).

I can't claim to be an ArcGIS expert. I'm wondering if anyone has ideas of what I could look at or what it might be.

I decompiled the code that does the setting of the extent and took a look at the code, but I can't really tell much without being able to debug into it and I can't do that since I don't have a reflector license and my trial is up.

Pretty sure this is some sort of SDE or ArcGIS Server issue, I just don't know what it would be.

Thanks!

Answer 1

Better answer is to set your map to be the full extent you want to display; versus relying on the Page to set the extent. In your map; you can define the initial extent to be the full view; or a area of interest; this will keep you from forcing the control to load the defautl extent (via the MapResourceManager) and then change extents.

You can use the MapResourceManager to define the initial extent for all the services you load; that might really be the better place to look; versus using the map-canvas itself.

Answer 2

Turns out the sysadmins installed Microsoft Forefront on the server. Which is fine. However, there is an option called "Real-time protection" which, if allowed, can monitor all running processes in real-time. This slowed down any queries against the server. I'm not sure why I didn't seem to notice it with other parts of the application. However, it was noticeable when opening an mxd from the server in arcmap.

Simple disabling real-time protection sped things up tremendously, including the code in question.