E
dit
A
ttach
P
rintable
r12 - 2014-04-16 - 14:14:17 - Main.gcovell
You are here:
TWiki
>
Deployment Web
>
DeploymentPlanningAndDesign
>
PerformanceDatasheetsAndSizingGuidelines
>
CaseStudyRTCPlanLoadingPerformance
<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%"> <!-- * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup, Main.TWikiDeploymentDatasheetsAuthorsGroup, Main.GrantCovell --> ---+!! Case study: Comparing RTC 3.0.1.3 and 4.0.3 plan loading performance </br> %DKGRAY% Authors: Main.GrantCovell, Main.ChetnaWarade, Main.MichaelFiedler</br> Last updated: July 11, 2013</br> Build basis: Rational Team Concert 3.0.1.3, 4.x %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> Planning is one of the most powerful and frequently used features of Rational Team Concert. Our clients are able to dynamically view and manage plans from very tiny team plans to multi-year large plans with thousands of items and complex team/owner/plan item relationships. With larger, more complex plans, some clients note sub-optimal performance of plan loading, have sought techniques to optimize their plan usage and have asked IBM to improve plan load response times. For the Rational Team Concert 4.x releases, the development team made significant improvements to plan loading behavior. This case study compared identically structured plans of varying sizes with the goal of determining the difference in plan load time between Rational Team Concert 3.0.1.3 and 4.0.3. Using the 3.0.1.3 release the larger plans took more than a minute to load while in 4.0.3 all plans, regardless of size or browser used, took less than a minute to load. In this study plans of all sizes loaded faster in 4.0.3 than in 3.0.1.3. Notably, plans with larger numbers of work items loaded proportionally faster in 4.0.3. *NOTE*: We delivered substantial changes to plan loading in 4.0.3. Several customers identified a prevalent use case / datashape which prevented the plan-loading improvements from being realized. For some 4.0.3 customers, there was a functional defect which prevented them from using plans; for other 4.0.3 customers, if they had timelines with data and workitems that weren't relevant to the current iteration, then they were retrieving extra data and didn't see plan-loading improvements. These defects were fixed in hot fixes for 4.0.3, and were resolved in 4.0.4 and 4.0.5. All customers using 4.0.5 or greater should see the plan-loading improvements. ---++ Disclaimer %INCLUDE{"PerformanceDatasheetDisclaimerEndToEnd"}% ---++ Summary Plan loading in Rational Team Concert 4.0.3 has improved markedly over version 3.0.1.3. Changes were made in the 4.0 release and the 4.0.1 release, but the most substantive changes were made in the 4.0.3 release. For simplicity we are comparing the 3.0.1.3 and 4.0.3 releases only. The degree of improvement will vary from environment to environment, and is influenced by many factors including hardware, operating system, database, network latency, datashape, workload, workload rate and number of concurrent users using the application. In our tests with plans of varying work items, we observed that the greatest improvement in plan loading times is for those plans with many work items. ---++ Topology Two separate physical configurations were built to evaluate plan performance. No part of the two server configurations use virtualization. Both the RTC 3.0.1.3 and 4.0.3 environments are running on RHEL 6.3 on IBM 7914 AC1 / x3550 M4 servers at 2.5 GHz with 32 GB RAM and 24 logical processors (each physical machine has two sockets, six cores-per-socket, and two threads-per-core which in total appear as 24 logical processors). In the 3.0.1.3 environment the application server is !WebSphere 7.0.0.27, and in the 4.0.3 environment the application server is !WebSphere 8.5.0.2. The database in the 3.0.1.3 environment is DB2 9.7.0.8, and in the 4.0.3 environment the database is DB2 10.1.0.2. In the 3.0.1.3 environment the JTS and CCM servers are co-located on the same server, and in the 4.0.3 environment the JTS and CCM servers are on separate servers. The max heap setting (-Xms) for the JTS and CCM JVMs is set to 6144 MB. The plans are accessed using Internet browser applications from a client machine located in a separate lab (the client is located in Littleton, Massachusetts, and the servers are located in Raleigh, North Carolina). The average ping time between the clients and servers is 88 ms (in a multi-instance ping sample, the min ping was 48 ms and the max was 173 ms). This multi-state latency is typical of many WAN installations. User authentication is managed by IBM Tivoli Directory server on AIX platform. Network latency between LDAP authentication server and CLM application server is less than one second. The web server is IBM HTTP Server 8.5. These topologies are derived from the E1 Topology documented at [[https://jazz.net/library/article/820#Enterprise_Distributed_Linux__DB2][Standard Topology (E1) Enterprise - Distributed / Linux / DB2.]] <img src="%ATTACHURLPATH%/topology_3013.jpg" alt="CLM v3.0.1.3 Topology" /> <img src="%ATTACHURLPATH%/topology_403.jpg" alt="CLM v4.0.3 Topology" /> ---++ Methodology Using automation we developed five plans of different sizes, characterized as plans with 300, 600, 1200, 2400 and 9600 work items. Specific plan characteristics are indicated in the table below. <img src="%ATTACHURLPATH%/plancharacteristics.jpg" alt="Plan Characteristics" /> The five plans were accessed from a machine running Windows 2008 using three different browsers, Firefox (version 21), Chrome (version 27.0.1453.110) and Internet Explorer (version 9.0.8112.16421). Response times were measured using built-in web performance tools such as !HttpWatch and Chrome's Developer Tools, as well as stopwatches. Eight samples were taken for each combination of plan, browser and RTC version, and the averages and standard deviations calculated. Note that for the 9600-work-item plan in 3.0.1.3 for all three browsers that response times were rounded to the nearest second, and that to accomodate the Chrome Developer Tool's behavior of expressing times greater than 60 seconds as fractional minutes (eg. 1.1 minutes instead of 63.56 seconds) a combination of stopwatch and page additions were used to calculate times in Chrome for the 2400- and 9600-work-item plans. The plans were accessed manually as a single user against a server with no other load. Admittedly these are ideal times given there is no server load, but the purpose of these tests was to isolate and document 4.0.3 plan loading improvements. We also did not track client or server CPU activity. We expect that plan performance in an enviroment with active server load could be less dramatic depending upon server hardware, network latency, database, and the number of concurrent users and their workload and workload rate. ---++ Results This data table shows response time results comparing 3.0.1.3 and 4.0.3 using three browsers to access the five plans. Overall, 4.0.3 performance is better with generally lower ranges of response times (standard deviation). Note that in 4.0.3, all plans return in less than one minute where as in 3.0.1.3 the 2400- and 9600-work-item plans returned in more than a minute. <img src="%ATTACHURLPATH%/data.jpg" alt="Comparison of five plans loading in RTC 3.0.1.3 and 4.0.3 in three browsers" /> This bar graph averages the response times across the three browsers to show the relative performance improvements. Note that 4.0.3 response times improve as the size of the plans grows. <img src="%ATTACHURLPATH%/percentage.jpg" alt="Average percentage improvement, RTC 3.0.1.3 vs. 4.0.3" /> These graphs show the same data in the data table above, but grouped by browser. <img src="%ATTACHURLPATH%/threebrowsers.jpg" alt="Five plans in RTC 3.0.1.3 vs. 4.0.3 by browser" /> For the tests above, we used one type of plan view, the Iteration view. We also explored different views of a subset of plans. The default view is Iteration, but Ranked and Breakdown can be configurable defaults. For this exploration we stayed with Internet Explorer and RTC version 4.0.3 and looked at just the 300-, 600-, and 1200-work-item plan sizes. <img src="%ATTACHURLPATH%/403_ie_diffplans.jpg" alt="Three different plan views in RTC 4.0.3 with Internet Explorer" /> For all the tests above each plan had a constant ratio of open and closed work items. We took one plan size and explored different ratios of open and closed workitems to see if that made a significant difference. <img src="%ATTACHURLPATH%/diffopenclosed.jpg" alt="Different open/closed ratios in the same plan views in RTC 4.0.3 with Internet Explorer" /> ---++++!! For more information * Jazz.net article: [[https://jazz.net/library/article/593/][Getting Started with Planning in Rational Team Concert 4.0]] * Jazz.net article: [[https://jazz.net/library/article/594][Effective Planning with Rational Team Concert 3.0]] * Jazz.net article: [[https://jazz.net/library/article/657][Traditional planning: Managing formal projects in Rational Team Concert 4.0]] * IBM technote: [[http://www-01.ibm.com/support/docview.wss?uid=swg21612656][How to Improve Performance while loading large plans in the Web UI]] * Jazz.net wiki article: [[https://jazz.net/wiki/bin/view/Main/PlanLoading][Plan performance improvements in Rational Team Concert, Version 4.0.3]] * Jazz.net Deployment wiki article: [[https://jazz.net/wiki/bin/view/Deployment/RTCPlanLoading][Why does my RTC plan take so long to load?]] ---++++!! About the authors Main.GrantCovell has been working for IBM Rational software on performance-related things for nearly 10 years. He's now the Senior Performance Obsessor on the Jazz Jumpstart team. Before that, he managed the Rational Performance Engineering team. You can follow his Jumpstart team blog, called [[a href="http://ratlperfland.com/][Ratl Perf Land]]. Main.ChetnaWarade is has been a Software Engineer at IBM for over 9 years. She is part of the Rational Performance Engineering group. Main.MichaelFiedler is the team lead for Rational Team Concert's planning component. He has also been actively involved in Eclipse Lyo and OSLC. <sticky></div></sticky>
E
dit
|
A
ttach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
: r12
<
r11
<
r10
<
r9
<
r8
|
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
.