Services are slow - how to increase speed of display

[LuciHawkins]

Hi,

We have been getting our new 10.1 server ready for production.  When you compare the services and flex web app that we have on our 10.0 to our new 10.1 there is a noticable difference when you pan or zoom.  The 10.1 server is much SLOWER.  Any ideas on how to increase the speed?

Thanks,

Luci

[nicogis]

see http://wiki.gis.com/wiki/index.php/Server_Software_Performance

[LuciHawkins]

Great reading but I am still confused... 

So, in "Pooling"  Each instance creates a SOC connection?   So, if I have 1 min and 5 max, there will be anywhere between 1 and 5 SOC instances running?

In "Processes"  -  if I run "low isolation" - because we do not edit, we just view data, and use 8 instances per process, each SOC instance from "Pooling" can have 8 user connections?

Now,  If the above is true and I have 70 services, do I need hardware to support 350 (70 services X 5 Max instances) SOC connections or do they share SOC connections between services?

On the 10.0 machine we have every layer as its own map service (about 70 of them) and were told by ESRI that is the preferable method.  On the 10.1 server I set it up the same way and was told again that was the preferred method.  Is it? 

We are running the SQL geodatabase and Arcgis Server 10.1 on the same Windows 2008 R2 server that has 2 Xeon E5-2640 (6 core) processors with 32 gb ram. 

I moved the config-store directory back to the C: drive because everyone seems to think that slows Server 10.1 down.  I still have all of the other Directories on the 😧 drive (1 TB) because the C: drive is only 278 GB.

Any help will be greatly appreciated!

Thanks,

Luci

[nicogis]

1) In High isolation deploys single-threaded ArcSOC processes (one service instance per process). So you could have until 5 max arcsoc.exe
2) If you run "low isolation" and set 8 instances per process, each SOC process has until 8 service instance



see http://wiki.gis.com/wiki/index.php/Server_Software_Performance#Process_threads

you speak 'connection' but remember that: An application that uses an instance of a pooled service only uses it for the amount of time it takes to complete one request (for example, to draw a map or geocode an address). After the request is completed, the application releases its reference to the service and returns it directly to the available pool of instances. In statistics you can understand if the number of instance min-max that you have set for your service is Ok (see timeout in http://resources.arcgis.com/en/help/main/10.1/index.html#//015400000343000000)

[Asta_KristinOladottir]

see http://wiki.gis.com/wiki/index.php/Server_Software_Performance

Thank you RandallWilliams, do you know where I should store the external capability file?

[LuciHawkins · Accepted solution]

After days of troubleshooting the services I finally called ESRI Tech Support.  They determined that everything was fine with my server and my services but there was definite heavy SQL usage.  So, their database team called me and seemed to instantly know what my problem was.  It was the new "DEFAULTS" value for GEOMETRY_STORAGE in the dbtune table. In previous versions it was set to SDEBINARY, now in 10.1 it is set to GEOMETRY which is slower.  I recreated my database feature classes using the SDEBINARY for the spatial type and everything is back up to the same speed as it was in 10.0

I used the sde command line tools to change the default setting to be SDEBINARY so that future feature classes that are created will use that.  If we find that we need GEOMETRY for the spatial storage type we can always select it.

Thanks,

Luci

[JamalNUMAN]

After days of troubleshooting the services I finally called ESRI Tech Support.  They determined that everything was fine with my server and my services but there was definite heavy SQL usage.  So, their database team called me and seemed to instantly know what my problem was.  It was the new "DEFAULTS" value for GEOMETRY_STORAGE in the dbtune table. In previous versions it was set to SDEBINARY, now in 10.1 it is set to GEOMETRY which is slower.  I recreated my database feature classes using the SDEBINARY for the spatial type and everything is back up to the same speed as it was in 10.0

I used the sde command line tools to change the default setting to be SDEBINARY so that future feature classes that are created will use that.  If we find that we need GEOMETRY for the spatial storage type we can always select it.

Thanks,

Luci

Hi Luci,

I�??m experiencing the same problem and my web applications are really slow in displaying my maps.

I�??m thinking to publish data from file geodatabase instead of ArcSDE geodatabase (SQL server database) as I have been advised that file geodatabase is much faster than ArcSDE geodatabase. Replication could be used then to synchronize between the ArcSDE geodatabase (which is used as multiuser environment) and the file geodatabase (which is used as data source for publishing and thus URLs used in the web application can be faster)

I�??m not sure if Rebuild Indexes, Analyze Datasets and Compressing of the SQL server databse might have an influence to speed up reading the data from the SQL server database.


Best

Jamal

[LuciHawkins]

Hey Jamal,

We thought about going back to a file geodatabase but decided against it.  Some of our users wanted to be able to do tasks in our web app which would require a feature layer.  Because feature layers are only supported through SQL, we would have had a portion of our data in a SQL GDB and a portion in a file GDB and that would have been too much to maintain.  So far we are happy with the speed we achieved just by changing the spatial data type from Geometry to SDEBinary.

We have an end of the day cleanup where all users reconcile/post and remove their versions.  The data is then QC'd, reconcile/post to Default, Synchronized and the geodatabase is compressed.  We Analyze about once a week.  Having a good cleanup routine definitely helps with the speed of the geodatabase.


Good Luck!

Luci

[JamalNUMAN]

Hey Jamal,

We thought about going back to a file geodatabase but decided against it.  Some of our users wanted to be able to do tasks in our web app which would require a feature layer.  Because feature layers are only supported through SQL, we would have had a portion of our data in a SQL GDB and a portion in a file GDB and that would have been too much to maintain.  So far we are happy with the speed we achieved just by changing the spatial data type from Geometry to SDEBinary.

We have an end of the day cleanup where all users reconcile/post and remove their versions.  The data is then QC'd, reconcile/post to Default, Synchronized and the geodatabase is compressed.  We Analyze about once a week.  Having a good cleanup routine definitely helps with the speed of the geodatabase.


Good Luck!

Luci

Hi Luci,

Thank you for the answer,

�?� I couldn�??t figure out how the spatial data type could be switched from Geometry to SDEBinaryfor multiple feature classes.

[ATTACH=CONFIG]24955[/ATTACH], [ATTACH=CONFIG]24956[/ATTACH]

�?� Does this mean that keeping the versions will slow down access the database with URLs (from web applications)?

[ATTACH=CONFIG]24957[/ATTACH]

�?� While the �??Rebuild Indexes, Analyze Datasets and Compressing�?� does speed up accessing the database, why not to do it daily?

[ATTACH=CONFIG]24958[/ATTACH]

Best

Jamal

[LuciHawkins]

Hi Jamal,

1.  Unfortunately, No, I do not know of a method to change more than one at a time from Geometry to SDEBinary.

2.  No, I dont think that having the versions remain will slow it down to much.  I have only experienced lag when we have had major edit sessions and over 100,000 features were changed.  As soon as we reconciled, posted, and compressed everything sped back up.  We just have everyone delete their version at the end of the day so we know they have done the reconcile and post to our QC version.  If someone wants a version to do what-if scenarious that will not be posted to Default then we allow that one to remain.

3.  I dont see a problem with doing it daily.  We are probably smaller than most GIS departments and just find that end of week works for us. 

Good Luck!

Luci