Collaborative Lifecycle Management performance report: Rational Quality Manager 6.0.6.1 release

Introduction

This report focuses on Rational Quality Manager (RQM) version 6.0.6.1 performance using a large repository that contains 15 million test artifacts in total. This is a new benchmark in terms of scenario coverage, repository size, and database indexes.

Compared to previous standard performance regression reports for 1,000 concurrent users operating against an RQM server not enabled for configuration management and using a 10 million artifact repository:

• The scenario coverage for this report included additional use cases for editing of test suites, browsing of test suite results, and browsing of test case results. Full text search use case was excluded.
• The repository size was increased to 15 million artifacts.
• Additional database indexes were explored based on the test load to further improve performance.

Disclaimer

The information in this document is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multi-programming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.

This testing was done as a way to compare and characterize the differences in performance between different versions of the product. The results shown here should thus be looked at as a comparison of the contrasting performance between different versions, and not as an absolute benchmark of performance.

Summary of performance results

Throughput

Summary of page response times

The details are provided in section Median page response time breakdown.

Summary of OS resource utilization

• CPU utilization averaged about 35% on the RQM application server and 14% on the database server.
• The reverse proxy server, Jazz Team Server, and Jazz Authorization Server utilized relatively low CPU resources averaging 3% or less.
• Disk utilization averaged about 51% on the database server and less than 2% on the RQM application server.
• Memory consumption averaged about 40GB on the database server. Heap usage on the RQM application server remained stable within the allocated amounts.

The details are provided in section Resource utilization.

Appendix A: Topology

The topology under test is based on Standard Topology (E1) Enterprise - Distributed / Linux / DB2.

The specifications of machines under test are listed in the table below. Server tuning details listed in Appendix D: Key configuration parameters

N/A: Not applicable. vCores = Cores with hyperthreading

Network connectivity

All server machines and test clients are located on the same subnet. The LAN has 1000 Mbps of maximum bandwidth and less than 0.3 ms latency in ping.

Data volume and shape

The artifacts were migrated from 6.0.6GA repository which contains a total of 15M artifacts in one large project.

The repository contained the following data:

• 2,339 test plans
• 1,403,200 test scripts
• 1,403,200 test cases
• 5,612,800 test case execution records
• 5,612,800 test case results
• 140,320 test suites
• 5,000 work items(defects)
• 9,338 test environments
• 28,064 test phases
• 280 build definitions
• 66,458 execution sequences
• 140,320 test suite execution records
• 701,600 test suite execution results
• 46,661 build records

• QM Database size = 669 GB

The artifact maintains the following associations:

• each test plan is linked to 600 unique test cases, and 600 unique test scripts
• each test suite contains 500 test cases

In this test environment, the Configuration Management is not enabled.

Appendix B: Methodology

The test methodology involved collecting the standard one-hour performance test data using 1,000 concurrent users, repeating the test, and comparing the results.

Rational Performance Tester (RPT) was used to simulate the workload created using the web client. Each user completed a random use case from a set of available use cases. A Rational Performance Tester script is created for each use case. The scripts are organized by pages and each page represents a user action. The work load is role based as each of the areas defined under sequence of actions are separated into individual user groups within an RPT schedule.

The User roles, test cases and workload characterization section describes the configuration of the RPT schedule.

User roles, test cases and workload characterization

Test Cases

Execution Count

The average number of executions per scenario by 1,000 concurrent users generating the workload described above is shown below:

Response times

Appendix C: Detailed performance results

Median page response time breakdown

Browse Test Case Execution Records

Back to Test Cases & workload characterization

Browse Test Case Results

Back to Test Cases & workload characterization

Browse Test Plans & Test Cases

Back to Test Cases & workload characterization

Browse Test Scripts

Back to Test Cases & workload characterization

Browse Test Suite Results

Back to Test Cases & workload characterization

Bulk Edit of Test Cases

Back to Test Cases & workload characterization

Create Defect

Back to Test Cases & workload characterization

Create Test Case

Back to Test Cases & workload characterization

Create Test Plan

Back to Test Cases & workload characterization

Create Test Script

Back to Test Cases & workload characterization

Edit Test Case

Back to Test Cases & workload characterization

Edit Test Environment

Back to Test Cases & workload characterization

Edit Test Plan

Back to Test Cases & workload characterization

Edit Test Script

Back to Test Cases & workload characterization

Edit Test Suite

Back to Test Cases & workload characterization

Modify Defect

Back to Test Cases & workload characterization

Search Defect

Back to Test Cases & workload characterization

Simple Test Plan Copy

Back to Test Cases & workload characterization

Test Execution For 4 Steps

Back to Test Cases & workload characterization

View Dashboard

Back to Test Cases & workload characterization

View Dashboard with Login

Back to Test Cases & workload characterization

RPT network transfer

Resource utilization

OS Resource Utilization - Overview

CPU
Disk
Memory
Network

Garbage collection - JVM GC Charts

Verbose garbage collection (GC) is enabled by default to log the GC activities. Below is one example of the output from the GC log for each application.

WAS Liberty JVM Garbage Collection Charts for RQM and JTS Servers

QM
JTS

Appendix D: Key configuration parameters

JAVA_OPTS="$JAVA_OPTS -Xmx8g"
JAVA_OPTS="$JAVA_OPTS -Xms8g"
JAVA_OPTS="$JAVA_OPTS -Xmn2g"
JAVA_OPTS="$JAVA_OPTS -XX:MaxDirectMemorySize=2G"

Appendix E: Database server tuning

Indexes

########## to improve default browse XXX pages ##########
db2 'CREATE INDEX "EXECUTION"."TER_JZ_ARC_MOD_PRJ_ITM_ST" ON "EXECUTION"."EXECUTION_RECORD" ( "JZ_DISCRIMINATOR" ASC, "ARCHIVED" ASC, "MODIFIED" DESC, "PROJECT_AREA_ITEM_ID" ASC, "ITEM_ID" ASC, "STATE_ID" ASC )'
db2 'CREATE INDEX "EXECUTION"."TCER_JZ_PRJ_ARC_ENT_ITM_ST" ON "EXECUTION"."EXECUTION_TASK_RESULT" ( "JZ_DISCRIMINATOR" ASC, "PROJECT_AREA_ITEM_ID" ASC, "ARCHIVED" ASC, "END_TIME" ASC, "ITEM_ID" ASC, "STATE_ID" ASC )'
db2 'CREATE INDEX "EXECUTION"."TSER_JZ_ARC_ENT_PRJ_ITM_ST" ON "EXECUTION"."EXECUTION_TASK_RESULT" ( "JZ_DISCRIMINATOR" ASC, "ARCHIVED" ASC, "END_TIME" DESC, "PROJECT_AREA_ITEM_ID" ASC, "ITEM_ID" ASC, "STATE_ID" ASC )'
########## the following are function based indices for name search filters for large scale, only to add them to IBM DB2 v10.5 and above #################
########## to improve searching via applying keywords in the Name filter ##########
db2 'CREATE INDEX EXECUTION.NAMECOL_UPPER_TER on EXECUTION.EXECUTION_RECORD(UPPER(NAME_COL))'

The sample script to add these indexes can be found in the Attachments section at the bottom of this report.

Runstats

Typically, we run the following:

db2 REORGCHK UPDATE STATISTICS ON TABLE ALL

For the series of tests covered for this report, we also ran:

db2 'RUNSTATS ON TABLE "PLANNING"."TEST_CASE" ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE "PLANNING"."EXECUTION_SCRIPT" ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE EXECUTION.EXECUTION_RECORD ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE EXECUTION.EXECUTION_TASK_RESULT ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE PLANNING.TEST_SUITE ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE PLANNING.TEST_PLAN ON COLUMNS ( "NAME_COL" )  AND SAMPLED DETAILED INDEXES ALL  ALLOW WRITE ACCESS  TABLESAMPLE BERNOULLI ( 40.0 ) REPEATABLE ( 50 ) UTIL_IMPACT_PRIORITY 50'
db2 'RUNSTATS ON TABLE "REPOSITORY"."VERSION" WITH DISTRIBUTION AND DETAILED INDEXES ALL'

For more runstats commands, please refer to the upgrade guide for details.

About the author(s):

Related topics: Collaborative Lifecycle Management performance report: Rational Quality Manager 6.0.4 release

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?

Warning: Can't find topic Deployment.PerformanceDatasheetReaderComments