Plan Loading Performance Improvements in RTC 5.0.1

Authors: Daniel Pool, Vladimir Zahariev
Last updated: September 9, 2014
Build basis: Rational Team Concert 5.0.1

For Rational Team Concert 5.0.1 our plan loading performance improvements were focused on tree views. We found that the primary factor which differentiated loading of tree views from flat lists was loading of child items that are shown in this plan, but not scheduled for this plan. These items are referred to as "outplaced children". Focusing on outplaced children provided significant performance improvements for loading of plans using tree views. We tested these changes on physical hardware, on virtual machines, on a variety of server configurations, and on our production server, jazz.net. What we found is that for tree views, larger plans will commonly load 20% to 30% faster in Rational Team Concert 5.0.1 compared to the previous version. In real world test cases we observed that plans often have many levels of nesting with large numbers of outplaced children. In these cases we have seen performance improvements of 60% and better.

The scenarios tested were:

• Reopening a plan that was previously opened in another tab.
• Reloading the plan by reloading the browser window.
• Refreshing a plan using the plan refresh functionality of RTC.
• Opening a plan in the browser after clearing the browser's cache.

All testing was performed using Firefox 24 ESR. The numbers reported are the average of performing each operation 5 times.

Results of plan loading improvements

Following measurements show the comparison of plan load times in RTC 5.0.0 vs. RTC 5.0.1 in different server configuration environments.

400 Item Spring Test Plan on Physical Hardware with WAS and DB2

1000 Item Sprint Test Plan on Physical Hardware with WAS and DB2

400 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 200 ms. added latency

1000 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 200 ms. added latency

400 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 500 ms. added latency

1000 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 500 ms. added latency

400 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 900 ms. added latency

1000 Item Sprint Test Plan on Physical Hardware with WAS and DB2 - 900 ms. added latency

400 Item Sprint Test Plan on Physical Hardware with Microsoft SQL Server

1000 Item Sprint Test Plan on Physical Hardware with Microsoft SQL Server

400 Item Sprint Test Plan on Virtualized Server with WAS and DB2

1000 Item Sprint Test Plan on Virtualized Server with WAS and DB2

5000 Item Sprint Plan on Physical Hardware with WAS and DB2

5000 Item Release Plan on Physical Hardware with WAS and DB2

The next two measurements show the before and after times for enabling the deferred loading of outplaced children on jazz.net. This functionality was enabled on jazz.net in RTC 5.0.1 M2. These are real world use cases of plans used in the development of Rational Team Concert. The tests show times for loading these plans from our production server, jazz.net. Note that these timings were taken loading the plans in the work breakdown view.

Planning 5.0.1 Release Plan in RTC 5.0.1 M1 vs RTC 5.0.1 M2:

Product Backlog (CCM) in RTC 5.0.1 M1 vs RTC 5.0.1 M2:

Technical Details

Deferred Load of Outplaced Children

The biggest improvements come from deferring loading of outplaced children. In the APT 2.0 M1 Plan pictured below the defect "NPE in My Work View" is an outplaced child of the story "Improve Consumability of the Eclipse UI". The story "Improve Consumability of Eclipse UI" is planned for the APT 2.0 M1 Sprint. But its child, "NPE in My Work View", is planned for the APT 2.0 M0 Sprint.

Previous Steps to Load Outplaced Children

Previously these outplaced children were loaded when the plan opened. All the work items scheduled for this plan were loaded. Then the links from the planned items to children not scheduled for this plan were loaded. Then the linked child items would be loaded. This would repeat for as many levels of nesting as specified by the plan. This would take multiple round trips to the server to resolve, and each cycle would require significant processing on both the client and the server.

New Steps to Load Outplaced Children

Outplaced children are now fetched only when they are shown. This happens when a plan item with outplaced children is expanded. While the parent is expanding it will show a loading icon as the outplaced child items are loaded. This is generally quick as only the outplaced children for a single item are fetched.

Note that in some cases all children are filtered out of the plan view. A common example of this is if all children are resolved, and the plan is filtering resolved items. If all children are filtered, and there are outplaced children, then the expansion turn down will initially be shown. Clicking the expansion turn down will show the loading animation, and then the turndown will be hidden. This happens because once the outplaced children have loaded the client determines they are filtered.

Important Note About Plans with Accumulated Time

Plans with an Accumulated Time column will not benefit from deferred loading. Displaying accumulated time requires all children to be loaded on the client in order to correctly display accumulated time.

Increased Concurrent Requests

In order to load all work items and links more quickly we increased the number of concurrent requests used when loading links and work items for a plan. This takes advantage of the fact that the browsers supported in Rational Team Concert 5.0.1 allow a higher number of concurrent connections than browsers supported in previous versions.

Tuned Timing of Client Side Attribute Processing

The browser performs all plan load processing in the UI thread. In order to keep the browser responsive the client must break up the plan load processing so that UI thread can also respond to user input. We tuned the timing of the plan loading processing to eliminate gaps where the client was sitting idle while there was work to be done loading the plan.

About the authors

Daniel Pool and Vladimir Zahariev are members of RTC Tracking and Planning Team. They led the team efforts to improve plan loading performance in RTC 5.0.1 release. Daniel can be contacted at dbpool@us.ibm.com and Vladimir can be contacted at zahariev@us.ibm.com

Additional contributors: GrantCovell