How does Hub scale to meet Enterprise needs?

Last updated
Save as PDF

Last Updated: May 14, 2021 | Applicable Hub Versions: All

Answer

One of the benefits of Planview Hub is that it was designed with scalability in mind. Its architecture and core paradigms enable customers to flow a large number of artifacts between tools — spanning many different repositories, projects, and artifact types.

When considering scale within Planview Hub, there are two main factors to consider: throughput and manageability.

Throughput refers to the act of transferring data via Hub, and how quickly, efficiently, and seamlessly you are able to do so.
Manageability refers to time and effort required to manage your integrations. It can include time spent creating and modifying models, updating integration configuration, and creating field mappings, to name a few examples.

In this section, we will only cover scalability as it relates to throughput. To learn more about manageability, please refer to our User Guide.

Throughput can be impacted by the following factors, for large-scale integration scenarios:

Number and Rate of Artifact Creation and Modification: The single largest driver when it comes to throughput is the number of artifacts and their rate of change.
Type of Repository: Hub cannot account for the speed with which data moves through the end repositories. As such, you may notice slower processing in Hub if you are utilizing an older repository with less modern architecture.
Number of Projects: While an increase in the number of projects you are synchronizing will impact throughput to some degree, you will not see significant changes in throughput unless the increase in projects comes with a corresponding increase in the number of artifacts across those projects.
Network Latency: Network speeds and wait times may affect the rate at which Hub is able to retrieve and update artifacts between repositories.

Recommended Practices

The sections below outline recommended practices in order to improve throughput.

Note: Best practices can diverge depending on each specific use case. As such, please view the guidelines below as a set of general rules, which may be altered depending on your unique scenario. We recommend reaching out to the customer care team with any questions regarding your organization's specific use cases.

Hardware Sizing

For best results, Planview Hub should be deployed in an environment that has good network throughput and low latency to all repositories and databases involved in an integration.

Please see our Hardware Sizing Recommendations for Deployment Scenarios in our Installation Primer to review our recommendations for scenarios of various sizes.

Planview Strategy

Planview has worked hard to optimize throughput of artifacts in customer integrations, using two core strategies:

Smart Change Detection ensures that Hub is only retrieving artifacts that have recently been updated by an end user. By retrieving only the necessary information, Hub optimizes performance and processing time, while minimizing web traffic.
Flow Updates: When Hub does detect changes to artifacts included in an integration, only the fields that truly changed are written out. Again, this cuts down on traffic, processing power, and integration time.

Customer Configuration

While Hub has built in behind-the-scenes optimization, there are some key configuration updates customers can make if noticing slower performance.

Concurrency Limit

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 notice that Hub is placing too high a load on a specific repository, you can modify this setting. If setting a value is needed, we recommend starting with a value between 3-10 and engaging with support to determine an appropriate value for your specific environment.

The ideal Concurrency Limit is highly dependent on each customer's 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:

Notice Hub is placing a high load on the repository.
Try setting Concurrency Limit to 7.
Monitor performance for 10 minutes during a busy time.
If load is not reduced, try setting to 4.
Or, if load went down too much, or if changes propagate too slowly through Hub, try a higher setting such as 10.
Continue to monitor and adjust as needed.

You can learn more about the repository-based Concurrency Limit here.

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 users do not change it, unless they are working directly with Support.

You can learn more about the Integration Maximum Concurrency limit here.

Polling Interval

The Polling Interval refers to how frequently Hub will check for, and then flow, updates in each repository.

There are two intervals specified:

Change Detection Polling Interval: the time between polling requests to detect only changed artifacts. This defaults to 1 minute, but can be customized as desired.
Full Scan Change Detection Polling Interval: the time between polling requests to detect changed artifacts, in which all artifacts of a collection are scanned. This defaults to 10 hours, but can be customized as desired.

The recommended polling interval varies based on the repositories being integrated and on your organizational practices. If you are flowing artifacts with a high frequency of change, the default 1 minute interval may serve your needs. However, if you are flowing artifacts with less frequent updates (such as requirements), a longer interval may be preferred. Note that the polling interval assigned applies to all integrations in your Hub instance.

Configuration of External Repository and Server

Above, we have outlined several ways to configure Hub to ensure that throughput is maximized. Additionally, there are some practices at the repository level and at the server level, that will also facilitate improved throughput.

Though we recommend making use of Hub's built-in filtering capabilities as a first step, if you are experiencing performance issues, a repository query may help mitigate those issues. By creating a saved query in your repository that is accessible to Hub via an API, the burden is placed on the repository, rather than on Hub. This alleviates some of the work from Hub, and improves throughput. You can learn more about filtering and repository queries here.