Answer

The Concurrency Limit is set at the Repository level, and it limits how much work Hub can do in parallel in that repository. It does this by limiting the number of concurrent tasks where the connection is used. We recommend leaving this field blank/set to the default (having no specified limit), though if you are noticing that Hub is placing too high a load on your repository, you can modify this setting.

Beginning in Planview Hub version 18.4 and later, an Event Rate Limit can also be set to mitigate scenarios where an external repository is temporarily receiving an excessive API call rate over short periods of time. If customers notice that Hub is placing too high a load on their repository, we recommend first modifying the Event Rate Limit.  If that is insufficient, or if the source of the high server load is specifically due to having too many open connections on the external repository, the Concurrency Limit can be modified. 

If setting a value for the Concurrency Limit is needed, we recommend starting with a value between 3-10 and engaging with our Support team to determine an appropriate value for your environment.

The ideal Concurrency Limit is highly dependent on each unique environment. Determining the appropriate value is best achieved through experimentation, using feedback from performance monitoring to tune the value, and making adjustments as necessary. Setting the value too low when there is a large number of projects configured in your collections and a low Change Detection Polling Interval setting can potentially cause Hub to be unable to process artifact changes.

Here is a potential recommended workflow:

1. Notice Hub is placing a high load on the repository.
2. (If using Planview Hub 18.4 or later), work with customer care to set the Event Rate Limit field.
3. If this is insufficient, or if the source of the high server load is due to having too many open connections, try updating the Concurrency Limit with the guidance of customer care.
4. For example --
   1. Try setting Concurrency Limit to 7.
   2. Monitor performance for 10 minutes during a busy time.
   3. If load is not reduced, try setting to 4.
   4. Or, if load went down too much, or if changes propagate too slowly through Hub, try a higher setting such as 10.
5. Continue to monitor and adjust as needed.

The Integration Maximum Concurrency limit, on the other hand, is specified on the Settings screen. Though the word ‘concurrency’ is used in both, they are measuring different things. Thus, the Integration Maximum Concurrency limit cannot override the Repository Concurrency Limit (or vice versa). The Integration Maximum Concurrency limits how many activities Hub can process at once for each integration. Activities are shown on the Activity screen. This limit defaults to 10, and we recommend that you do not change it, unless you are working directly with our Support team.

As a general rule, you should not edit either of these values without consulting customer care. However, if you are experiencing a high load on a specific repository, we recommend working with Support to modify the repository-level settings (i.e., the Event Rate Limit and/or Concurrency Limit). On the other hand, if you are noticing performance issues across the board, we recommend that you work with Support to update the Integration Maximum Concurrency limit (or potentially the other Change Detection Interval Limits).

You can find additional information in our User Guide:

• Concurrency Limits 
• Integration Maximum Concurrency Limit & other Polling Interval Settings