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:
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 firstname.lastname@example.org
Vladimir can be contacted at email@example.com
Additional contributors: GrantCovell