PerformancePlanLoadingImprovements502 < Deployment

<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%">
---+!! Plan Loading Performance Improvements in RTC 5.0.2<img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/todo.png" alt="todo.png" width="50" height="50" align="right"> 
%DKGRAY% Authors: Filip Wieladek, Kevin Garsjo <br>
Build basis: RTC 5.0.2
%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>

In Rational Team Concert 5.0.2, plan loading performance has been drastically improved for specific data sets, stemming from investigations on specific planning REST calls. The investigation allowed the team to identify wasteful server-side processing, and replace the problem implementations with more performant ones. The REST calls in question are responsible for resolving and returning references to work item links, potential work item owners, categories and team areas. Any plan view displaying a category, owner, or link attribute will benefit from this work.

The team used the time taken to open specific plans as the testing metric for performance. For our testing purposes, time taken is measured as the elapsed time between refreshing a plan and the last plan loading message ("Loading additional data...") to disappear. In all refresh instances, the browser's localStorage was cleared to prevent skewed data due to caching.

---++ Testing Methodology

The plans tested contain views and data-sets specifically chosen to exercise the investigated service calls. Each plan is given a size, representing the relative size of its data set. The Small plan data-set is defined as follows:
   * The plan's process area contains 50 contributors
   * The plan's process area contains 5 team areas, with defined categories for each
   * The plan contains 1 work item, which in turn tracks 50 out-of-scope items

The medium plan scales the small plan by 10. The large plan scales the small plan by 100. Each plan uses a flat view, with no other options. The following columns are the only ones displayed:
   * Summary
   * Owned By
   * Filed Against
   * Tracks

When collecting results, 5 plan refreshes were made for each plan size. The highest and lowest outliers were discarded, and the remaining times were averaged together to form the final measurement.

---++ Results

For the specific plans, testing between 5.0.1 and 5.0.2 saw improvements ranging from 42% to 75%.

The small plan saw 75% improvement, while the medium plan saw 67%.

<img src="%ATTACHURLPATH%/smallMediumPlanLoadData_rc1.png" alt="Small and Medium Plan Load Data"/>

The large plan saw 42% improvement.

<img src="%ATTACHURLPATH%/largePlanLoadData_rc1.png" alt="Large Plan Load Data"/>

---++ Technical Details

Prior to the investigation, the getWorkItemAttributes() REST call delegated to methods that collected handles for contributors that were potential owners of work items in a plan. These handles were sorted before return. The comparator for this sort resolved the handles one-by-one to compare name values, a wasteful process that caused a repository round-trip for each individual handle per comparison. Plans with larger contributor sets suffered proportionally worse. The solution was to resolve all handles in a batch prior to sorting, requiring only 1 round-trip to the repository. This problem was also present while fetching team areas, and the solution was the same.

The getLinks() REST call also had handle issues, where handles were being resolved twice. The solution was to encapsulate the handle in an accessor method, which would resolve once and cache the result for future access.

---++ About the Team

Filip Wieladek and Kevin Garsjo are members of the RTC Tracking and Planning team. They led the 5.0.2 planning performance investigations, fixes, and testing. Fil may be contacted at filip_wieladek@ch.ibm.com, and Kevin may be contacted ad krgarsjo@us.ibm.com.

<sticky></div></sticky>

Attachments

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	largePlanLoadData_rc1.png	manage	17.7 K	2014-10-20 - 17:46	UnknownUser
png	smallMediumPlanLoadData_rc1.png	manage	21.8 K	2014-10-20 - 17:46	UnknownUser

This topic: Deployment > WebHome > DeploymentPlanningAndDesign > PerformanceDatasheetsAndSizingGuidelines > PerformancePlanLoadingImprovements502

History: r1 - 2014-10-20 - 17:51:48 - Main.kgarsjo

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.