E
dit
A
ttach
P
rintable
r2 - 2014-12-09 - 01:01:32 - Main.gcovell
You are here:
TWiki
>
Deployment Web
>
DeploymentPlanningAndDesign
>
PerformanceDatasheetsAndSizingGuidelines
>
PerformancePlanLoadingImprovements502
<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/new.png" alt="new.png" width="50" height="50" align="right"> %DKGRAY% Authors: Filip Wieladek, Kevin Garsjo <br> Date: December 8, 2014 <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 local storage 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. ------------------------------------- ---++++!! For more information * [[PerformanceDatasheetsAndSizingGuidelines#CLM_5_x][Performance Datasheets: CLM 5.x]] ---++++!! About the authors 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. -------------------- ---+++++!! Questions and comments: * What other performance information would you like to see here? * Do you have performance scenarios to share? * Do you have scenarios that are not addressed in documentation? * Where are you having problems in performance? %COMMENT{type="below" target="PerformanceDatasheetReaderComments" button="Submit"}% %INCLUDE{"PerformanceDatasheetReaderComments"}% <sticky></div></sticky>
E
dit
|
A
ttach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
: r2
<
r1
|
M
ore topic actions
Deployment
Deployment web
Planning and design
Installing and upgrading
Migrating and evolving
Integrating
Administering
Monitoring
Troubleshooting
Community information and contribution guidelines
Create new topic
Topic list
Search
Advanced search
Notify
RSS
Atom
Changes
Statistics
Web preferences
NOTE: Please use the Sandbox web for testing
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
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
.