(r5) ScenariosToBeInvestigated < Deployment

Engineering Lifecycle Management Wiki - Deployment
Community information and contribution guidelines
~~EditAttach~~Printable
TWiki > Deployment Web > CLMExpensiveOperations > ScenariosToBeInvestigated
Revision 5 - 2016-05-02 - 22:13:47 - TimFeeney
e<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%">
---+!! CLM Operations to Investigate as Potentially Expensive%RED%(DRAFT)%ENDCOLOR% <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/uc.png" alt="uc.png" width="50" height="50" align="right"> 
%DKGRAY% Authors: Main.TimFeeney <br>
Build basis: The Rational solution for Collaborative Lifecycle Management (CLM) and the Rational solution for systems and software engineering (SSE) v6.0.1.
%ENDCOLOR%</div></sticky>

<!-- Page contents top of page on right hand side in box -->
<sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;">
%TOC{title="Page contents"}%
</div></sticky>

<sticky><div style="margin:15px;"></sticky>

This page captures CLM operations that may potentially be expensive but need further investigation to characterize and confirm.  See the parent topic containing the [[https://jazz.net/wiki/bin/edit/Deployment/CLMExpensiveOperations][known]] list.

%RED%Note: The information herein is a work in progress and is continually being reviewed/refined%ENDCOLOR%

|   %BLUE% *Table 1: Summary of CLM Operations to Investigate* %ENDCOLOR%   |||||
| *Product* | *Scenario* | *Scenario ID* | *Best Practice* | *Investigate* |
| [[#Rational_DOORS_Next_Generation][Rational DOORS Next Generation (DRAFT)]] | [[#Comparing_local_configurations_w][Comparing local configurations with large number of artifacts]] | DNG_Compare_Configuration | link | [[https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWorkItem&id=106102][106102]] |
| |||||
| [[#Rational_Team_Concert][Rational Team Concert (DRAFT)]] | [[#Concurrently_loading_a_large_num][Concurrently loading a large number of large configurations]] | RTC_Load_Workspace | link | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389280][389280]] |
| ^ | [[#Import_of_large_Microsoft_Projec][Import of large Microsoft Project plans]] | RTC_MSP_Import | [[#Best_Practices_for_Import_of_lar][link]] | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389355][389355]] |
| ^ | [[#Import_of_large_CSV_files][Import of large CSV files]] | RTC_CSV_Import | link | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389357][389357]] |
| ^ | [[#Export_of_large_Microsoft_Projec][Export of large Microsoft Project plans]] | RTC_MSP_Export | link | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389358][389358]] |
| ^ | [[#Export_of_large_number_of_work_i][Export of large number of work items to CSV file]] | RTC_Workitem_Export | link | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389359][389359]] |
| ^ | [[#Large_bulk_edits_of_work_items][Large bulk edits of work items]] | RTC_WI_Bulk_Edit | link | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389361][389361]] |
| ^ | [[#Adding_many_build_result_contrib][Adding many build result contributions to build result]] | RTC_Add_Build_Contribution | link | [[https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/389278][389278]] |
| ^ | [[#Loading_a_large_plan][Loading a large plan]] | RTC_Load_Plan | [[#Best_Practices_for_Loading_a_lar][link]] | [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389362][389362]] |
| |||||
| [[#Rational_Quality_Manager][Rational Quality Manager (DRAFT)]] | [[#Comparing_local_configuratio_AN1][Comparing local configurations with large number of artifacts]] | RQM_Compare_Configuration | link | [[https://jazz.net/jazz02/web/projects/Rational%20Quality%20Manager#action=com.ibm.team.workitem.viewWorkItem&id=151178][151178]] |
| |||||
| [[Jazz_Reporting_Services_all_repo][Jazz Reporting Services (all reporting technologies) (DRAFT)]] | | | | |
| |||||
| [[#Global_Configuration][Global Configuration (DRAFT)]] | [[#Creating_streams_in_a_global_con][Creating streams in a global configuration hierarchy]] | GC_Create_Stream | link | [[https://jazz.net/jazz/web/projects/Jazz Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389494][389494]] |
| ^ | [[#Creating_a_baseline_staging_stre][Creating a baseline staging stream from a global stream hierarchy]] | GC_Create_Baseline_Staging | link | [[https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389497][389497]] |
| ^ | [[#Creating_a_global_baseline_or_co][Creating a global baseline (or committing a baseline staging stream) from a global stream hierarchy]] | GC_Create_Global_Baseline | link | [[https://jazz.net/jazz/web/projects/Jazz Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389495][389495]] |

---++ Rational DOORS Next Generation

---+++ Comparing local configurations with large number of artifacts

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWorkItem&id=106102][work item 106102]] %ENDCOLOR%

---++ Rational Rhapsody Design Manager

---+++ Importing or moving a large model to DM
When you import a large model, or move a large model (in actively-managed mode) to DM, the server could potentially become unresponsive, especially when others are working in that same stream. DM notifies users that an import is occurring. 

---+++ Operations that load a large model
Some operations require loading a model in its entirety; if the model is large, it can impact server memory and processing. Such operations include: 
   * Generating code from a model 
   * Exporting a model (using “Save as”) 
   * Creating a table layout in Rhapsody with too broad a scope 

Use smaller related models to reduce the system demands; this is also a best practice.

---+++ OSLC integration to DNG/DOORS 
Rhapsody DM can manage OSLC links between model elements and requirements artifacts in related DOORS and DNG projects. When doing so, DM retrieves all available requirements from the projects and all defined links from the DM server. The integration synchronizes to find new requirements/links. If the requirements project is large, the link management can be resource-intensive.

To reduce resource demands, use a filtered view (e.g. collection, module) to narrow the amount of requirements to retrieve. 

---++ Rational Team Concert

---+++ Concurrently loading a large number of large configurations
This may occur with many continuous builds doing many concurrent loads of large configurations (those approaching the file/folder limit as described in [[https://jazz.net/wiki/bin/view/Deployment/EnvelopesRangesAndLimits#RTC][RTC Limits]]).  

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389280][work item 389280]]. %ENDCOLOR%

---+++ Import of large Microsoft Project plans
How long an import takes depends on the quantity of items in the plan and their nested structure.  For example, an import from an MS Project file containing 2000 tasks could take up to 30 minutes on the first import and 8-10 minutes on subsequent imports depending on server configuration and load.  Consider also the memory demands of an import which will take approximately 100KB for each task being imported over and above the memory needed for typical RTC operation.  In most cases, import of Microsoft Project plans is an infrequent operations, generally performed at the start of a project.  However, if imports are to be a frequent occurrence, be sure that the server memory allocation has ample spare capacity.  Note the numbers provided are based on testing in a non-production environment.  

%RED% Further investigation to better characterize a 'large' Microsoft Project plan and the load generated when importing one is tracked by [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389355][work item 389355]]. %ENDCOLOR%

---++++!! Best Practices for Import of large Microsoft Project plans
If your MS Project file contains more than 1000 tasks, we recommend you import or export during off-hours or when the server is lightly loaded.

---+++ Import of large CSV files
Similar to an import of a Microsoft Project plan, an import of a large CSV file can keep the server busy and drive memory usage.  However, unlike the plan import, CSV file imports occur more frequently and are often part of a round trip update.  

%RED% Further investigation to better characterize a 'large' CSV file import and the load generated when importing one is tracked by [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389357][work item 389357]]. %ENDCOLOR%

---++++!! Best Practices for Import of large CSV files
For more than 1000 work items, it is best to wait for off hours or until the server is lightly loaded.  

---+++ Export of large Microsoft Project plans
Similar to an import, export time and load are dependent on the size and complexity of the plan. The impact is primarily to memory on the server.

%RED% Further investigation to better characterize a 'large' Microsoft Project plan and the load generated when exporting one is tracked by [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389358][work item 389358]]. %ENDCOLOR%

---+++ Export of large number of work items to CSV file
Exporting a large number of work items primarily impacts memory on the server.

%RED% Further investigation to better characterize a 'large' number of work items and the load generated when exporting them is tracked by [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389359][work item 389359]]. %ENDCOLOR%

---+++ Large bulk edits of work items 
Performance and load driven by this scenario is a function of the number of work items and number of attributes changed as each work item is changed and saved one at a time.

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389361][work item 389361]]. %ENDCOLOR%

---+++ Adding many build result contributions to build result
When a large number of contributions (compilation contributions, Junit tests, downloads, log files, links, work item references, etc) are included on a build result, because of the way they are stored (single data structure), the server could spend a lot of time marshalling and unmarshalling the persisted contributions when adding/deleting contributions. At best this is a slow running operation, however, should there be a large number of concurrent builds performing similar work (adding many build result contributions), the potential for impact to the server increases.

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/389278][work item 389278]]. %ENDCOLOR%

---+++ Loading a large plan
The RTC plan editor provides users with great flexibility to display plans in customized and flexible configurations.  In order, to provide rapid display of custom plan configurations, the RTC planning editor must fetch all the details of each work item when loading plans.  Consequently, when the scope of a plan includes a large number of work items, loading of such plans can drive server load.  We have greatly improved plan loading performance with each release by deferring the loading of out placed "child" work items or by allowing users to turn on and configure server side plan filtering to avoid loading plan types that will never be displayed in plans.  

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=389362][work item 389362]]. %ENDCOLOR%

---++++!! Best Practices for Loading a large plan
For large plans using the traditional RTC plan UI, and running RTC 6.x or later, if the plan loading performance is not acceptable, consider configuring the plan to perform server side filtering. Note that server side filtering is turned off by default.  See [[https://jazz.net/downloads/rational-team-concert/releases/6.0?p=news#plan_performance][plan performance]].  Check also that you are not displaying costly attributes in the plan such as Gantt charts.  Breaking the plan into a more manageable size and removing items you never need to display in the plan may help.

In addition, releases of RTC (5.0.2 and forward) include a new planning tool, called RTC Quick Planner which allows teams to edit plans in a fast and fluid manner. RTC Quick Planner loads plans much faster, as it only loads only a few screens of the plan at a time and then loads additional plan items as you page through the plan and ask to display them. Developers, Scrum Masters and other users who need to load plans quickly and create new work items dynamically, should be encouraged to use RTC Quick Planner for their daily plan operations. 

---+++ Slow running operations
---++++!! Synchronizing attributes after a large amount of change in attributes for a work item
There are two ways for [[http://www-01.ibm.com/support/docview.wss?uid=swg21372230][synchronizing work item attributes]].  First, using the RTC Eclipse client, run a query and select a set of work items then right click the type column and select Synchronize Attributes.  This process would only affect the selected work items and response time is not a concern unless the client selected thousands of work items.  The second method is to trigger the sync from the process configuration editor by the "check attributes usages in repository" action.  This process could take a long time as it sync all work items created with all work item types within the same project area.  If there are thousands of work items in the project area with a large number of attributes changes, it can take some time to complete (a warning is presented to the user).

---++++!! Loading a work item with a large amount of customized attributes
When there are over 100 custom attributes in a work item type, loading of a work item of that type can be slow from the client perspective but isn't known to drive server load.

---++ Rational Quality Manager

---+++ Comparing local configurations with large number of artifacts

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz02/web/projects/Rational%20Quality%20Manager#action=com.ibm.team.workitem.viewWorkItem&id=151178][work item 151178]]. %ENDCOLOR%

---++ Jazz Reporting Services (all reporting technologies)

---++ Global Configuration

---+++ Creating streams in a global configuration hierarchy
When you create a new stream for a global configuration, it may also generate new streams for the DNG, RQM, and DM contributions, and may need to traverse the global configuration hierarchy as well to create global streams from global baselines.  The time to generate the streams depends on the complexity of the configuration hierarchy, the number of local application (DNG, RQM, and DM) baselines in the hierarchy, and number of versioned artifacts in each. 

Because the local application (DNG, RQM, DM) creates its streams, most of the demand is placed on those servers.  If there are a large number of baselines to create in the application servers, or if the GCM hierarchy is very deep or complex, you might want to create the new streams during a period of light usage.  

%RED% This scenario needs further analysis to characterize further and establish best practices to limit impact.  See [[https://jazz.net/jazz/web/projects/Jazz Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389494][work item 389494]]. %ENDCOLOR%

---+++ Creating a baseline staging stream from a global stream hierarchy
When you create a baseline staging stream (BSS) for a global configuration hierarchy, you also create a new baseline staging stream for each global stream in the hierarchy. The time to do this depends on the number of global configurations in the hierarchy, how deeply nested they are, and the number of custom properties and links they have. 

%RED% This scenario needs further analysis to confirm it can be expensive and to characterize further.  See [[https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389497][work item 389497]]. %ENDCOLOR%

---+++ Creating a global baseline (or committing a baseline staging stream) from a global stream hierarchy
When you create a global baseline (or commit the baseline staging stream) for a global configuration hierarchy, it requests baselines for each local configuration from the contributing application (DNG, RQM, or DM). It also traverses the global configuration hierarchy, committing each included baseline staging stream and requesting local configuration baselines for those streams as well. 

Similar to creating streams from the global baseline, much of the processing is done by the contributing application servers (DNG, RQM, and DM). If there are many local configurations, consider creating the baseline when usage of those servers is light. 

%RED% This scenario needs further analysis to characterize further and establish a best practices to limit impact.  See [[https://jazz.net/jazz/web/projects/Jazz Foundation#action=com.ibm.team.workitem.viewWorkItem&id=389495][work item 389495]]. %ENDCOLOR%

-------

---+++++!! Related topics: [[DeploymentWebHome][Deployment web home]], [[DeploymentWebHome][Deployment web home]]

---+++++!! External links:          

   * [[https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=386674][Identify the expensive user scenarios in the products that destabilize the system]]

---+++++!! Additional contributors: Main.TWikiUser, Main.TWikiUser

</div>
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.