Silk Performer's dynamic workload-assignment functionality matches your specific load-test requirements to the replay capabilities of available agent computers at execution time. For example, if your load test requires a workload that can be delivered only by an agent computer with an installed SAPGUI client, dynamic workload-assignment functionality can ensure that your test's workload is assigned only to available agents with installed SAPGUI clients. Further, you can configure the percentage of required workload, in the number of virtual users, that must be allocated to each agent, thereby ensuring that agents are not pushed beyond their load capacities.
Dynamic-workload assignment allows you to account for variations in resource requirements. For example, approximately the same amount of resources is required to drive 2,000 virtual Web users over a Web replay interface as is required to drive 20 virtual SAP users over a SAPGUI replay interface. Based on maximum virtual-user-per-replay-capability settings that you configure, the dynamic-workload assignment algorithm allocates appropriate workload levels to agents. This approach does not necessarily result in each agent continuously driving its maximum supported load. You can define the percentage of maximum-potential workload that must be allocated to each individual agent within the cluster. For example, if an agent can drive 2,000 Web users and you set the agent-resource-utilization setting to 50%, only 1,000 Web users are allocated to that agent. The remaining workload is allocated to other agents that possess the same Web-user capability.
An advantage of dynamic assignment of workload to agent clusters is the manner in which the successful execution of tests is not contingent on your maintaining a static test-execution environment. For example, if an agent's name changes or becomes unavailable, Silk Performer can dynamically assign the unavailable agent's workload to an available agent in the same cluster with the required capabilities. This approach eliminates many of the challenges involved in maintaining a static test environment and is of particular value when Silk Performer load tests are managed and executed based on predefined schedules in Silk Central. Silk Central can run tests against agent clusters rather than individual agents. Issues that do not require consideration from the Silk Central perspective include the health of individual agents and the manner in which workload is balanced across agents.
Agent computers remain available to all workloads until the moment of test execution because they are not reserved or assigned to any one specific workload. When a Silk Performer controller identifies an available agent on which it intends to run a test execution, the controller momentarily locks the agent to prevent conflict conditions with other controllers. After the test completes, the agents are unlocked and made available to other tests.