Rational EM products (RTC EE, RDz, RD&T, RAA, …): recommendations and “educated guesses” for limitations

March 20, 2014

In the past couple of years, I’ve helped customers in their adoption and deployments of CLM, RTC, RQM and RRC-DNG. Based on their recurrent questions for correct sizing and scalability handling, I shared some limits / educated guesses for limitations in the blog post “CLM,RTC,RQM,RRC: recommendations and “educated guesses” for limitations“.

RationalEM-TableofLimitsNow that my focus has moved to Rational Team Concert Enterprise Extensions (RTC EE) and the Rational solution for Enterprise Modernization, I want to share similar content for RTC EE, RDz, RAA, … Following the same approach. [Tip for you] if you’re already familiar with my previous post, you may skip straight to the tables below and ignore the two following sections which detail some terminology and purpose aspects.

In the Tables below, there are columns for Limits and Alert zone. Let’s clarify how we define them:

  • Quantified data: the (maximum) number of….
  • Limit: a hard limit of the product. Meaning that you cannot go beyond this value.
  • Alert zone: based on experiences with customers, internal tests and development teams, it’s around these values that we start seeing performance issues. If you’re approaching these values, we’d suggest you monitor your system closely to detect any performance degradation before it becomes critical. WARNING: while provided figures are educated guesses and practical rules of thumbs, you could still find that your environment functions perfectly beyond these limits  (e.g. if your environment is particularly fine-tuned). In a similar way,  some intense usage could show that these recommended values are too optimistic…

As a consequence, it’s important to understand this post is NOT an attempt for replacing existing resources (see the References section) that provide extensive views on CLM performance and tuning topics. We encourage administrators and project managers to read them as they both include finer-grain information and insist on the key aspect of not loosing the “bigger picture”.

What’s the use of the following tables then ?

Answer: they’re here to HELP YOU quickly figure out if you’ve reached some known limitation or if you’re getting close to a threshold  (again: on the basis of a typical/average environment) requiring due monitoring of your environment.  To this regard, these tables are COMPLEMENTARY with existing resources and concentrate information ALREADY available ((but yet disseminated) on multiple medias/sites/forum posts/etc.

Now, let’s go straight to the tables…

RTC EE
Quantified data Limit Educated guess / Alert zone Reference(s)
Files
   Files in a component (<v4.0) 2000 Dev team inputs
   Files in a component (>=v4.0)  –  2000 [Share 2013] (s. 8)
Build
   builds in parallel (*) number of build engines supporting the build definition
   team builds in parallel (<4.0.3)  –  1 (**) Jazz.net forum, EEBAW workshop labs (p. 63)
   team builds in parallel (>=4.0.3)  1 Jazz.net WI (***)
   team builds in parallel (>=4.0.6)  –  1 Jazz.net WI (****)
 
(*): this includes personal and team builds.
(**): multiple concurrent team builds of your dependency build may result in unnecessary rebuilds of the same program. You should prevent this by only configuring one supporting team build engine. Additional engines may be added for personal builds only. Check referenced EEBAW workshop labs for more details.
(***): from this 4.0.3 version level, when running multiple team builds in parallel, all but the 1st treated of the concurrent build requests will fail and error log will contain the following message: “Found a build “20140319-xxxxxxxxxx” “currently running.  Running concurrent builds is disallowed.
(****): constraint possibly relaxed by both setting the mentioned property and by making sure you use non overlapping subset. Typical use case is (only) for building different programs (a.k.a non-incremental team builds).

Ξ

RDz
Quantified data Limit Educated guess / Alert zone Reference(s)
 – [RDz v9 InfoCenter] Tuning considerations

Ξ

RD&T
Quantified data Limit Educated guess / Alert zone Reference(s)
developers supported  –
  • 3-5 per RD&T server (Desktop machine)
  • 15-25 per RD&T server (Server class machine)
[Share 2012] (s. 32)
defined System z CPs (*)
  • 1 (1090-L01 model)
  • 2 (1090-L02 model)
  • 3 (1090-L03 model)
[Redbook] (p.12)
defined System z CPs (*) associated to a single zPDT instance
  • one less than the # of processor cores on the base Linux system (**)
 3-4 (***) [Redbook] (p.12)
zPDT instances  1 (per System z CP) [Redbook] (p.12)
emulated I/O devices  1024 [Redbook] (p.21)
 
(*): or mixture of CPs, zIIPs, zAAPs, and IFLs.
(**): an exception exists for a single core, which may be used with reduced zPDT (check p.3 of the referred Redbook).
(***): as per the I/O capability of the underlying PC and various “SMP effects”. Check p.12 for more details. Note: for configurations including multiple z1090 tokens, check p. 13 of referenced Redbook.

Reference for functional restrictions and scope exclusions inherent to a RD&T usage (in comparison to a real mainframe):

  • while these topics are not targeted in this document, for you awareness, you could find a consolidated list in the following resource (slide 25).

Ξ

RAA
Quantified data Limit Educated guess /Alert zone Reference(s)
number of levels for impact analysis  100 [WSAA InfoCenter] (p.47)
max. size of a scanned file  5 Mo (*) [devWorks forum]
 
(*): default value extendable through a property. Check referred forum answer for details.

References:

  1. [Deployment wiki] Performance datasheets and sizing guidelines
  2. Rational Team Concert 4.x sizing report for z/OS
  3. Rational solution for CLM 4.0 performance tuning guide for z/OS  (Oct 2012)
  4. General Link: Rational Developer for System z (RDz)
  5. General Link: Rational Development and Test Environment for System z (RD&Tz)
  6. General Link: Rational Asset Analyzer (RAA)

Acknowledgment/Credit: thanks to the authors of the cited documents above and more generally to the Jazz community who collaboratively provides accurate information through library articles, forums questions & answer, etc..


CLM,RTC,RQM,RRC/RDNG: recommendations and “educated guesses” for limitations

September 5, 2013

As part of the Jumpstart team, I help our customers in their CLM adoption and deployments. Customers raise questions on the sizing of their CLM environment, the topologies to adopt, etc. The questions I hear most often are:

  • How many users (total or concurrent) can my CLM environment support ?
  • RTC rollout at our company is close to reach a second milestone (additional teams will use the tool). What planning (HW/SW) should we have wrt. these modifications?
  • We have this huge number of CLM (RTC/RQM/RRC-RDNG) artefacts. Will my CLM environment still handle this without any performance degradation as we continue adding artefacts into our repository ?
  • What are the intrinsic CLM product limitations and – if one is concerning me – what approach should I adopt to keep on working smoothly with my CLM ?
  • etc.

First of all, depending on the CLM version you’re running, central places to check are the CLM 2011 Sizing Guide and the CLM 2012 Sizing Guide which include an “Artifact Sizing Guidelines” section summarizing “the recommendations on artifact sizing that will ensure optimal performance of the repository when the data sizes increase significantly“.

Foreword to the reader:

  • This post follows the “cheat sheet/how to” format I’ve used in earlier posts for CLM Reporting or OSLC-related topics. As a consequence, if you’re already familiar with this post (and know exactly what you’re looking for), you may want to navigate directly to the tables: JTS tableRTC tableRQM tableRRC/RDNG table.
  • If you’re interested by a similar content for Enterprise Modernization products (i.e. RTC EE, RDz, RD&T, RAA, etc.)  by IBM Rational, check this dedicated blog post.

Now back to the core of this post:

Tables

Tables are provided. OK. But what do we call a Limit and an Alert zone ?

  • Quantified data: the (maximum) number of….
  • Limit: a hard limit of the product. Meaning that you cannot go beyond this value.
  • Alert zone: based on experiences with customers, internal tests and development teams, it’s around these values that we start seeing performance issues. If you’re approaching these values, we’d suggest you monitor your system closely to detect any performance degradation before it becomes critical. WARNING: while provided figures are educated guesses and practical rules of thumbs, you could still find that your environment functions perfectly beyond these limits  (e.g. if your environment is particularly fine-tuned). In a similar way,  some intense CLM usage could show that these recommended values are too optimistic…

As a consequence, it’s important to understand this post is NOT an attempt for replacing existing resources (see the References section) that provide extensive views on CLM performance and tuning topics. We encourage administrators and project managers to read them as they both include finer-grain information and insist on the key aspect of not loosing the “bigger picture”.

What’s the use of the following tables then ?

Answer: they’re here to HELP YOU quickly figure out if you’ve reached some known CLM limitation or if you’re getting close to a threshold  (again: on the basis of a typical/average environment) requiring due monitoring of your environment.  To this regard, these tables are COMPLEMENTARY with existing resources and concentrate information ALREADY available but yet disseminated on multiple medias/sites/forum posts/etc.

What if… you can’t find what you’re looking for in the following tables ?

Answer: in such case, there MAY not be soft/hard limit on it. You should check the References section at the bottom of this post and check for the latest information (esp. from the CLM sizing guides).

Ξ

JTS
Quantified data Limit Alert zone Reference(s)
Concurrent user sessions  – 400-2000+ Purple Book
Jazz user id length  – 250 bytes Jazz.net forum

Ξ

RTC 
Quantified data Limit Alert zone Reference(s)
Concurrent user sessions  –  300-500+ (per CCM instance) Purple Book
   Example: “CLM Sizing Strategy” (v4.0.6 – April 2014)  –   – 100-600 concurrent users. See report/environment details.
   Example: “Performance Report” (v5.0 – June 2014) 1200 concurrent users. See report/environment details.
Planning – Work-items
   WIs in a plan (<= v2.0) 2048 Jazz.net article
   WIs in a plan (>=v2.0.0.1)  –  250-500+ (impacts plan display time + questions ability from user to grasp several 100s of WIs in one plan) Jazz.net forumJazz.net forumPurple Book, RTC 4.0.3 Plan performance improvement
   WIs in a project area/repository  – Jazz.net forum, Jazz.net article
   WI attachment size  50 MB  If increasing this value or systematically using large attachments: be aware of the possible impact on DB growth and CLM performance in general. See how to change this value in TechNote, Jazz.net forum
   WI “Estimate” attribute  1 year  – Jazz.net forum. A  presentation-enforced limit.
   WI custom attribute length > Small String (*) 250 bytes Jazz.net article (RTC v4.0)
   WI custom attribute length > Medium String (*) 1000 bytes Jazz.net article (RTC v4.0)
   WI custom attribute length > Large String (*) 32768 bytes Jazz.net article (RTC v4.0), Enhancement 160469
   WI custom attribute length > Medium HTML (*) 1000 bytes Jazz.net article (RTC v4.0)
   WI custom attribute length > Large HTML (*) 32768 bytes Jazz.net article (RTC v4.0)
Queries
   Query results
 1000 results Jazz.net forum. Note: this default value could be increased but be aware of the possible negative impact on usability / server performance.
Planning – Timelines
   Timelines  2048  (see recommended approach in the forum post’s answer) Jazz.net forum
SCM
   Files/folders in a single component (CLM 2011)  50K (split into multiple components if required) Jazz.net forumJazz.net article
   Files/folders in a single component (CLM 2012, RTC 5.0)  100K (split into multiple components if required) Jazz.net forumJazz.net article, Jazz.net forum,
   Suspended change-sets by individual user  300 (for not slowing down operations) Jazz.net article
   Components in workspaces and streams  500 (as tested by IBM) Jazz.net article , Task 176441 (in progress)
Build
  Build definitions associated to a build engine ( < v4.0.3) 2048 TechNote
OSLC
   oslc_cm.pageSize parameter (when querying work-items) 100 Jazz.net RFEJazz.net forum

(*): text-based

Ξ

RQM
Quantified data Limit Recommendation Reference(s)
Concurrent user sessions  –  100-150+ (per QM instance) Purple Book
   Example: “CLM Sizing Strategy” (v4.0.6 – April 2014)  – 350-500 concurrent users. See report/environment details.
   Example: “Performance Report” (v5.0 – June 2014) 1000 concurrent users. See report/environment details.
TER (Test Execution Record) name length  250  – Jazz.net forum
TCERs bulk generated from test plan wizard  500 Work-around article, RQM defect, WAS maxParamPerRequest
TCERs bulk changed/removed at once tbd  tbd Jazz.net forum, Jazz.net forum, WAS maxParamPerRequest
Records in a datapool / test data 2000  – Jazz.net enhancement
Character limit: Description field of a Lab Resource 250 Jazz.net enhancement
Number of categories defined on an artifact type 50 RQM defect, RQM defect
Feed entries per page ( < 4.0.4)  512  – Jazz.net forum, RQM defect
“Large Record Count” (SQL query result set generated by OOTB BIRT reports) ( >= 4.0.5)  –  10K TechNote, Jazz.net defect
Attachment size using UI Jazz.net enhancement
Attachment size using CLI ( Command-Line Interface) ( >= 4.0)  50 Mo Jazz.net article (for how to change this default value, see the Comments section). Note: if increased, be aware of the possible negative impact on usability / server performance.
TCERs runnable off-line and at once (>=4.0) 50 4.0 InfoCenter

Ξ

RRC-DNG/RDNG
Quantified data Limit Recommendation Reference(s)
Concurrent user sessions (< v4.0.1)  200+ Purple Book
 (>= v4.0.1)  400+ Purple Book
   Example: “CLM Sizing Strategy” (v4.0.6 – April 2014) 300-400 concurrent users. See report/environment details.
   Example:  “Performance Report” (v5.0 – June 2014) 400 concurrent users. See report/environment details.
Coexistence with DM (Design Manager) on the same box (in v.4.x and v5.0.x)  Incompatible  – Jazz.net forum (related to the converter component)
Instances of RM application per JTS (<= v4.0.6) 1 4.0.3 InfoCenter, Jazz.net article, Plan Item
RM Projects per RM application / JTS  200+ Jazz.net article
Number of undos in edit mode  20 TechNote
Number of displayable links (>= v4.0.1)
  • 60 (IE7)
  • 100 (other browsers)
Jazz.net forum
Number of artifacts selectable in the Artifact view 50 Enhancement 71080, Jazz.net forum
Using ReqIF
   Imports to DNG from DOORS (>= v4.0.1)
  • 5000 modules
  • 200K objects (total)
Jazz.net article, Jazz.net forum
   max depth supported for import 3 Jazz.net forum

References:

  1. CLM 2012 Sizing Report

  2. CLM 2011 Sizing Guide
  3. Rational Team Concert (RTC) 2.0 sizing guide
  4. Rational Team Concert 4.x sizing report for z/OS

  5. The Deployment wiki
  6. Jazz Performance: A Guide to Better Performance” by D. Toczala (Feb 2013). A.k.a the “Purple Book
  7. Sizing and tuning guide for RDNG (Rational DOORS Next Generation) 5.0

Acknowledment/Credit: thanks to the authors of the cited documents above and more generally to the Jazz community who collaboratively provides accurate information through library articles, forums questions & answer, etc..


Jazz/CLM ETLs performances: a view on release-to-release comparisons

August 1, 2013

Recently, I’ve had a deeper look at ETLs performances. This topic is sensible to our customer as full ETL load could last up to several days !

Based on work-items tracking activity and interactions with our development, support team and performance teams, I came up with a personal summary. I found it interesting to be shared with Jazz/CLM Administrators to get up to speed on performance of such ETLs.

Firstly, let’s start with the existing and customer-oriented information:

ETLs performance comparison between CLM versions 3.0.1.2 and 4.0.

Available in article “Rational solution for CLM 4.0 “Extract, Transform, and Load” Performance Report“.

It’s considering the “D1” topology (note: the article is little bit misleading as the provided URL link points directly… to the “E1” / Enterprise topology. I have notified the authors already).

A simplified summary (which should not prevent you from reading the full outcome of the ETL comparison) follows:

  • RTC ETLs: stable performance
  • RQM ETLs: 20% performance degradation (expected by dev team)
  • RM DM ETLs: significant improvement
  • Star ETL: no major issue

Secondly, let’s continue with the information provided for advanced readers

ETLs performance comparison between CLM versions 4.0.2 and 4.0.3

Available in [Plan Item 248546] “Ensure no ETL performance regressions are found when comparing CLM 2012 Mod 3 ETLs to 4.0.2“.

It’s again considering the “D1” topology.

Status (as for Aug. 1st, 2013) is “Done”. Navigating to the latest comments of the Discussion tab will show you available Excel spreadsheets (Java ETLs for RRDI, DM ETLs for Insight)  .

Finally, mentioning the plans for improving subsequent ETLs performance comparisons:

ETLs performance comparisons for forthcoming 4.x versions

Performance team have plans (be aware that plans are subject to change) to:

  • publish some automated ETL tests for later minor version of CLM 4.x
  • improve the analysis of performance data from the ETLs.

The related WIs are listed below:

Also citing some material of interest (but to a lesser extent from a customer perspective as these resources are part of the Jazz development wiki) as well:

Note: be aware the previous resources are subject to the following statement: “Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly“.

Finally, mentioning some related information (captured in the Deployment wiki)

…. and recalling a basic statement

If you’re concerned that the ETLs performances may have degraded after a particular CLM upgrade, you would need to keep in mind the amount of RTC WIs, RQM test cases, RRC artefacts, etc. has certainly increased since you last run a full ETLs load. This remark for avoiding comparing apples and oranges…


%d bloggers like this: