How to optimize the use of Reuse and Sync in Jama for better performance

By Shabnam posted 10-12-2015 17:12

  
Reuse and Synchronization in Jama is a powerful feature that can help Jama customers create and manage items in a more efficient way. The different scenarios that can be implemented using Reuse are described in detail in the Jama help guide. Cache updates such as checking permissions, verifying if the items being reused have been reused previously and updating nodes in the Explorer Tree of source and target project destination. Reusing a large number of items, for example, can put a high load on the Jama server and impact the performance of other functionalities within the application. 
Independent of the Jama server system configuration, there are several factors that correlate directly with the execution time of a reuse operation and the amount of load that it puts on the server. We highly recommend our customers be aware of these factors and keep the following in mind when using Reuse and Synchronization:
  • Avoid reusing large numbers of items. In order to reuse a container (i.e. Component, Set or Folder) start with the lowest level container, whether it is a Set or Folder, and reuse each sub-component one-by-one.


If the lowest level component has a large number of items, use the list view and reuse items in a smaller batch (e.g. 50 items instead of reusing all of them at once). A safe number for reusing items in a batch may vary based on the specifications of the Jama application server, the database server and the database type and configuration. Given the varying degrees of data complexity, system configuration, and Jama usage, it's difficult to put an exact recommendation on an upper boundary for Reuse and Sync. Our 2015.2 release includes optional notifications to warn users when a Reuse could impact performance. The in-app alert will be appear when users initiate a Reuse or Sync of more than 250 items. Users have the option to permanently dismiss this message, as they may not be experiencing any issues environment.


  • Reusing relationships and mirroring them impacts Reuse performance. When a user selects Include related items and mirror relationships, Jama will reuse related items as well as reusing the actual item. For example, reusing 1 item with 10 relationships and mirroring those relationships is similar to reusing 11 items. Be mindful of the number of relationships of the items that are going to be reused. The batches of items in each Reuse operation should be even smaller than with Reuse operation without related items.

  • When choosing a target destination, use the option to Manually select location(s) for reused item(s). Selecting this option puts less load on Jama when doing a reuse. Create the target destination in the target project first and manually select that in the Reuse window.

  • Avoid using Sync All. Reuse and Synchronization are similar in Jama, therefore similar factors contribute to how much load a Sync can put on Jama server. Avoid using Sync All and instead sync items one-by-one. Similar to reusing relationships, syncing relationships can also be taxing as the number of relationships grows.


As mentioned earlier, Jama checks the permission of the user on the target destination for Reuse. Permissions are complex, and assuring that each user has the right access level in each item is a taxing operation in Jama. This operation is especially taxing as the number of concurrent users in Jama grow. Therefore, Reuse could be slower in larger datasets and when the number of concurrent users grow.
Make sure to choose the Reuse and Sync options wisely and if possible perform these two operations in less busier hours of the day. 

Jama is continuously focused on improving overall system performance and will continue to publish updates with new releases. Jama also offers consultancy services to assist customers with the best approach in using Reuse and Synchronization to implement a workflow specific to each organization. 

#tutorial
4 comments
182 views

Comments

10-22-2015 16:23

Thank you Harald and apologies for delay in my response. That makes sense. Whether to add more SQL Server indexes (or optimizing SQL Server indexes in general) is something that we to need rely on our on-premises' customers (their DBA) judgement as it is something that can vary based on how customers use Jama. The missing index report that you sent us a while back is a very good report to refer to and decide whether adding index can actually improve performance based on users' usage or not. Adding unnecessary indexes has its own costs. 

10-15-2015 19:37

Yes

10-15-2015 14:32

Thank you Harald for your input. Do you usually "Sync" the items that you "Reuse"? GlobalId is the column that is looked up when items are synced and that is why I am asking. 

10-13-2015 12:06

We frequently use reuse on complete projects (more than 10K items) to create release snapshots including relationships. Another motivation is to decouple the development of features for the next release from finalizing a release.

We have added the following index to achieve good performance at doing that with large projects frequently:

CREATE NONCLUSTERED INDEX [ix_active_document_globalid_idx] ON [dbo].[document] (
[globalId] ASC,
[active] ASC,
[organizationId] ASC,
[projectId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO