Tuning Service Architecture: Are Views or Individual Services Better?

[KevinWyckoff1]

I would like to get feedback on what architecture will provide the best performance. I need to display data from a handful of feature classes for different maps and applications. Am I better off publishing a seperate feature service for each application? Or would I get better performance publishing one feature service, and then creating a view from that in Portal for the different needs? Both approaches will work. But with limited resources, which will provide the best performance for my users?

[berniejconnors]

How do you define "a handful"?  Personally I think you should identify the feature classes that will be used most frequently.  Those ones should be published as a single feature class per map service.  And if you have less than 20 feature classes I think you could easily publish one map service for each feature class.  Other things to consider:

• feature classes that are closely related should be published in the same map service, such as water lines and fire hydrants or roads and bridges.
• a feature class that is frequently updated and may require downtime during the update should be published alone in the map service.
• Feature classes that will be used infrequently can be published as shared instances - as opposed to a dedicated instance.

Once you have your services published you can look at some statistics for your map services by routinely running this python script or creating reports with the System Log Parser.  You can use the info to make adjustments to your map services.

Good luck,

Bernie.

[KevinWyckoff1]

@berniejconnors We had an incident last week where performance tanked, so I am trying to identify strategies to avoid this problem in the future. I have System Log Parser and Monitor running, so I can see what is occurring. Responding to those issues is another story. I have a total of 22 services running now that connect to 43 feature classes. I have 4 services running now that are only subtly different and are used to publish content in external applications, these services comprise roughly 90% of traffic on our server. I wonder if it would be more efficient to consolidate those services, and differentiate them with views at the Portal level?

[berniejconnors · Accepted solution]

If those 4 services account for 90% of your traffic they should each be their own service and their min and max instances should be increased to minimize queing.  Are you using a shared pool for the least popular services?  That will free up resources.  All the other services in the middle can be dedicated instances but have their min and max instances reduced.  These changes should reduce the max instances running at the same time and also reduce the memory load.

To prevent performance from tanking you may want to schedule a reboot of the system.  We reboot our servers twice a week but I am aware of others that reboot nightly.  When our performace tanks we run a stop / start script to shut down all services and restart them.  This only takes a few minutes per server.  It is better than waiting for performance to recover and it is much more elegant than a server reboot. 

I also run a report each week day to report all requests that run longer than 60 seconds.  We extract these records from the web server log on the web adaptor.  This has helped us identify poorly configured apps and stupid requests from users.  The "Search" widget in our most popular WAB app was configured to search all attributes on our parcel map service instead of just the parcel ID field.  This made every execution of the Search widget very slow.  It is also important to use "equal" instead of "like" when you configure the Search widget.  if you use "like", any indexing on the table will be ignored.  Your queries must use "equal" to take advantage of indexing.  It was quite embarassing when I discovered this problem - I configured the Search widget in the WAB app and caused all of these slow requests.

Additionally, you could request more RAM for your server.  You have spent a lot of money on software - it does not make sense to hamper performance with low hardware resources.

Bernie.