This article provides information about IBM Rational Requirements Composer (RRC) 4.x project sizing in terms of number of artifacts in projects.
Sizing guidelines for Rational DOORS Next Generation have appeared as part of the Performance Datasheets And Sizing Guidelines
since the 4.x release of Rational Requirements Composer. Also see
the RDNG migration guide
for equivalent guidance for the 6.x release.
Artifact numbers, Queries and Performance
Data being displayed in the RRC application is fetched using SPARQL
queries. These queries are requested by the RRC application and are executed on the Jazz Team Server (JTS). RRC takes care of working with the result set.
The scope of any query in RRC is a project
. This optimizes time and resource consumption. However, if all the data is placed in one project, this scoping has very little effect. The resource consumption and processing time of queries is directly proportional to the size of the project it is being run against. The size depends on the number of requirement artifacts like heading, text, images, tables, modules, folders, etc.
Keeping this in mind, having the right partition of data into multiple projects and folders in the repository is important to get optimal performance out of Rational Requirements Composer.
A good size for a project, module, and folder would be:
50,000 artifacts per project
Artifacts per project should not exceed 50,000 and these include folders, modules, module artifacts and collections. In case there are a high number of images, tables which in turn increase size of artifacts, consider a lower artifact number per project.
4000 artifacts per module and folder
This also helps to improve readability. As a best practice start with creating a folder structure in the project and avoid adding too many artifacts directly in the root folder.
There are other artifact types that need consideration, number of links within project and cross project that could increase as well (based on the above project, module and folder size limits an average of 4 links-per-requirement is considered good).
Identifying Project Size
You can periodically monitor the number of artifacts/resources in the repository/project. The quickest way to identify that the number of artifacts in the repository is based on the artifact ID of the most recently created artifact. However, since the ID is unique across the entire repository, it would not give you the right information if you looking for number of artifacts within the project.
To identify the number of artifacts within a specific project you can run a SPARQL query. SPARQL queries can be executed on the RRC built-in administration panel
, Under Debug > SPARQL Query
In the query window, set the custom SPARQL query scope to the project and check pre-count. Run the following query
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rm: <http://www.ibm.com/xmlns/rdm/rdf/>
PREFIX rmTypes: <http://www.ibm.com/xmlns/rdm/types/>
PREFIX rrmReview: <http://www.ibm.com/xmlns/rrm/reviews/1.0/>
PREFIX nav: <http://com.ibm.rdm/navigation#>
PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/>
SELECT (count (distinct *) as ?count)
?resource rdf:type rm:Artifact
Under the results column you would see
is the number of resources in the project the query is being run against. Following is a snapshot of the results
This includes artifacts, artifacts in modules, modules, collections, and folders. If the number is above 50,000, it would be a first indication for you to start with a new project area.
To determine the number of links replace
in the above query.
There is no theoretical limit on the number of artifacts that can be created in projects/modules. The largest current tested limit is 315,000 artifacts in a repository. These artifacts were spread across 75 projects.
The test data used for these sizing tests represents an extremely large repository compared to most customer environments. We chose this data size to test the limits of the RRC application with unusually large data volume. The data shape details are shown in the table below.
| Artifact type
| Module artifacts
| Non-module artifacts
| Views (public/private)
| Tags (public/private)
| Index size on disk
|| 51 GB
For details on the results of the scalability and performance tests conducted in an RRC-only deployment, with record of hardware/topology used along with the data volume tested against, see the following Sizing and Tuning Guides:
Consider the enterprise topology where the Jazz Team Server (JTS) and the RRC application resides in their own JVM.
Look up the Recommended Topologies
described in the deployment wiki
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?