ArcGIS Enterprise: Is It a Good Idea to Load Test Shared Services? (Beginner)
The Shared Service Instance Pool
When people talk about load testing an ArcGIS Enterprise Site, such conversations typically involve the consumption of dedicated or hosted feature services.
For many years, dedicated and hosted services have provided a fast, dependable mechanism for consuming high-traffic map resources online. This has not changed.
However, there is another type of resource to provide maps to users: the Shared Service Instance Pool.
Introduced in 10.7, the shared instances pool make it easier to view and query services that are still important but where memory usage is favored over performance.
This allows for high service density publishing (e.g., being able to publish and have running many services) at the expense of some speed and throughput. It can be a good trade-off considering that for many organizations, there are generally more shared service candidates than dedicated or hosted.
From this advantageous characteristic, shared services have been a true game changer. But, from a load testing perspective there are some considerations.
Note: As a GIS administrator, assume all shared services have an equal weight of importance with each other. Also assume that dedicated services take a higher priority than shared services.
Should Shared Services Be Load Tested?
The $64,000 Question! As a performance analyst, this question may come as your publish services to the Site.
While it can be very tempting to load test shared services to understand their scalability profile, there are several reasons why this strategy does *not* make sense:
- If scalability was paramount, the service should be moved to dedicated
- Shared services can still scale (e.g., support multiple, concurrent requests for the same item) but this is not its primary function
- The administrator has already designated the service to favor memory usage
- By configuring the service as shared, it is expected that the service will not be requested frequently
- If the service occasionally has slower or slightly slower response times, that is okay
- Testing such services steals hardware resources from the dedicated services
- Dedicated services are the MVP services, do not try to have the shared services compete with them
- Dedicated and hosted are the go-to mechanisms for service scalability
- By testing or frequently sending requests shared services, (limited) system resources like CPU and Memory can be drawn away from the services that need it for delivering fast performance to users
- Test Plan Management Challenges
- It is not uncommon for Sites to have dozens or hundreds of shared services
- Assuming all shared services are equal, the test plan for effectively testing and profiling a hundred or more shared services could be daunting and difficult to manage
A Site has a Mix of Shared and Dedicated Services, Can the Dedicated Ones Still Be Tested?
Yes. Understanding the performance and scalability profile of dedicated services is still valuable information to have for deploying and managing the Site optimally. Test dedicated services as your normally would.
Can Shared services be tested if that is the only instance pool type published?
There are no technical limitations that prevent shared services from being load tested.
While it is certain possible to run such a test, it is not recommended for the reasons above.
Analyze and Monitor the Site Periodically
The popularity of services can increase or decrease over time. Periodically analyzing the traffic patterns of service requests can help provide administrators with information to configure and manage the Site optimally. This means that as some services are requested more frequently (or it is anticipated that they will be), they can be manually moved from being a shared service to a dedicated service.