Best Practices for Configuring LQE For Performance and Scalability

Hardware Recommendations

All hardware recommendations for Lifecycle Query Engine are contained within IBM Documentation topic: Configuring Lifecycle Query Engine with Jena or Link Index Provider with Jena for improving performance and scalability.
LQE rs have documented their system requirements and also documented a LQE rs performance guide.

Validating or re-indexing a large data source

Validating all the TRS feeds that are registered in the Lifecycle Query Engine or LDX index can increase your confidence in the quality of your reports and help you troubleshoot missing, stale, or extra artifacts. TRS Validation works by itself, without accessing Lifecycle Query Engine or LDX. It compares only the actual and expected content in TRS feed. Reference Troubleshoot Configuration-aware Reporting for futher discussion on when this appropriate.

Note:

• Do not run more than one TRS validation operation at a time for a given TRS.
• If the application server is stopped during a TRS Validation operation, then, when the server is restarted, the TRS validation is not automatically restarted and it is in an unknown state. The admin user must set the option to clear the cache when starting a new validation.

There are occasions where the entire data source needs to be recreated. For example, after DOORS Next performs a full rebase operation. The next section addresses how to optimize this use case, for large systems.

Recommendations for optimizing throughput during a large LQE data source reindex or validate

When validating TRS Feeds, we recommend 1GB+ of free temp disk space for each set of 1 million TRS entries

Large deployments of the Engineering Lifecycle Management will create a large amount of large selections. Selections are stored in the relational database in both versions of LQE (Jena-based and "rs"). We recommend that you amend the Selections Relational Database Batch Size: to at least 10000 (Default 42. Max: 50,000). The impact of this will be to make larger, and therefore faster updates of the large selections at all times. This is especially important when there are large changes to the data source, such as a complete reindex after a full rebase (in DOORS Next).

For reindexing TRS Feeds:
Batch Queue Size: 5000 (default 500)
TRS HTTP Cache Max Entries: 5000 (default 100)
Write Queue Size:500 (default 25)
Process queue size: 500 (maximum is 1000)
Batch Size for Writes: 100000 (default 2500)
Batches Between Status Writes: 1
Selections Relational Database Batch Size:25000.

IF the above settings are adopted for a reindex of a DOORS Next data source, then to avoid the application becoming a bottleneck, especially on a production system, ensure that to size the configuration cache to match the number of configurations.

a) Execute the SQL SELECT COUNT (*) FROM RMUSER.VVCMODEL_CONFIGURATION where type in (0,1,2);
b) Set the "Number of Active (nonarchived) configurations in the Repository" query
-Dcom.ibm.rdm.configcache.size={# of configs from query}
c) set the Xmx/Xmn in server.startup to accommodate the new cache size (2GB per 1000 entry)

Related topics: Deployment web home, Deployment web home

External links:

• IBM

Additional contributors:

• KrzysztofKazmierczyk