Skip to content

Capacity & Concurrency Allocation to Projects and Users


In Worksoft SaaS, for each type of subscription (UI/Functional/API Testing, Volume Testing) that a domain is subscribed to, finite capacity (max hours of test execution per a specific time window) and concurrency (max number of parallel tests that could be run) is available. So far, the capacity and concurrency that is available at the domain level was 'shared' across all the projects within that domain and the users that had access to those projects 'shared' that capacity or concurrency.

You will be able to allocate (distribute) the capacity and/or concurrency that is available at the domain level to projects and/or users within the domain, based on the needs and projected usage patterns within the projects and by the users that have access to those projects. This allows projects or teams that execute more tests or more hours of tests to be allocated higher capacity and/or concurrency. You will also be able to adjust the capacity and/or concurrency allocated to the projects and/or users as the needs or usage patterns change from time to time.

You will also be able to set an execution priority (precedence) for tests triggered for execution within a project and or users 'relative' to the tests executed within other projects or triggered for execution by other users. For those of you that are familiar with the 'nice' command in Linux and Unix, the execution priority works in a similar fashion. The lower the execution priority that is assigned, the higher precedence/priority that is given to tests executed by specific users or within specific projects.

The visual below illustrates the power of this feature. The picture showcases for a (fictitious) domain that has two different subscriptions (a) UI/Functional/API Testing and (b) Volume Testing how the capacity and concurrency available at the domain level is distributed to various projects and users.

  
Below given table explains what it means when we say 'Reserved', 'Max Allowed' and 'Execution Priority'.
Reserved The concurrency that you want to 'reserve' for the specific project from that available at your Worksoft SaaS domain level. The reserved concurrency will NOT be allowed to be used by any other project within your Worksoft SaaS domain. This value cannot exceed the sum of reserved concurrency for all projects for which such reserving was done.
Max Allowed The maximum concurrency that you want to allocate to the specific project from that available at your Worksoft SaaS domain level. Obviously, this number has to be higher than the concurrency, if any, reserved, for the project. This value cannot exceed the concurrency available within your Worksoft SaaS domain and cannot exceed the sum of reserved concurrency for all projects for which such reserving was done.
Execution Priority This is a numeric value you can optionally assign to the set the precedence/priority for execution of tests within this project relative to other projects within your Worksoft SaaS domain. The higher the number the lower the precedence. The execution priority can be set to an integer number greater than 0 and lower than 10,000.
In the above image that illustrates the fictions domain with multiple projects and different combinations of concurrency and capacity allocations. Refer to the below table for the possible conditions/challenges that you would come across and the expected behavior in those conditions.
Condition Expected Behavior/Outcome
Project B, User #1 'Max Allowed' concurrency is not provided
'Max Allowed' is a mandatory field and if it is not provided it the Worksoft SaaS will throw an error
Project A the reserved capacity at the project level is '24' and if you want to allocate capacity for User # 3 say '15'. 
The system will not allow you to add capacity more than the reserved capacity.

Sum of the 'Users Reserved Capacity' should not exceed the 'Project Reserved Capacity'.
Project B reserved concurrency is 2 and if allocate for User # 2 the reserved concurrency is as 3 Sum of the Users Reserved Concurrency should not exceed the Project Reserved Concurrency.
In this scenario, the concurrency should either be distributed evenly or allocate the reserved concurrency to a single user.
Adding reserve capacity for User # 3 in Project D Capacity specified at the user level(s) should not cross the project level Capacity.

Here the project level capacity allocated is '0' as the entire capacity is reserved  by the Projects 'A', 'B', and 'C', you may not be able to reserve the capacity, however, you may still use the 'Max allowed' capacity allocated for the project with the execution priority for the User set as 3 .

The allocation and deallocation of capacity and/or concurrency to projects and/or users can be done very easily using three new services available within the Worksoft SaaS QaCONNECT REST API . Refer to the 'Account' section in the docs page of Worksoft SaaS QaCONNECT REST API. For details on the services, click here.

You may be thinking, "Ok, Using the three new powerful services I can allocate and maintain (adjust) the capacity and/or concurrency that is available at the domain level to projects and/or users. But how do I get visibility into the how the capacity and/or concurrency is currently distributed?". Don't worry. We now have a new (excel) report called "Subscription Capacity and Concurrency Allocation Report" that is available as part of the 'Subscription Usage' report set within Worksoft SaaS Analytics.




Feedback and Knowledge Base