Performance tuning for the Rational DOORS database and client

You can improve the performance of the IBM® Rational® DOORS® database and client by changing the hardware configuration and the requirements management artifacts and processes.
You can improve the performance of the database and client in these areas:

Server and network

The Rational DOORS database is a single-threaded server that performs file-based handling. If hardware permits, the server can complete hundreds of operations a second, but only one file is processed at a time. The distance on the network from the client to the server can affect performance. For network storage, the storage area network (SAN) solution is supported, but network attached storage (NAS) is not supported.

To improve performance:
  • Maximize the disk speed and processor speed on the database server.
  • Reduce the distance on the network from the client to the server. Require ping times of less than 50 milliseconds for reasonable performance. If ping times are 50 milliseconds or greater, you can use Citrix virtualization to improve performance.
  • If you are using Rational DOORS Web Access, locate the interoperation server near to your database server on the network.

Memory

The database server has modest memory requirements: 2 GB of RAM is sufficient for most projects. However, because Rational DOORS is a document-based application, when you open a module, all data in the module is loaded into memory. If the module contains links to other modules, those modules are loaded in the background. If you have large modules that contain many objects and many links to other modules, memory usage can rise significantly. Module export operations and Rational DOORS eXtension Language (DXL) processing also consume memory and can slow performance.

The desktop client for Rational DOORS version 9.5 and later supports Large Address Aware (LAA) memory management. With LAA, you can increase the virtual address space of the client to 3 GB of memory on 32-bit systems and 4 GB on 64-bit systems. For more information about configuring memory with LAA, see Installing the Rational DOORS client.

Rational DOORS version 9.5.1 and later include memory optimization that reduces memory consumption. Rational DOORS version 9.6.0 and later includes a 64-bit client, which increases the amount of memory that is available.

History and baselines

The record of activity in a module is stored in a history file. The module history, which grows as team members add object content and links, is loaded in the memory when you open the module. To avoid slowing performance, you can reduce the amount of history that is saved by setting configurations for particular module and object attributes. A simple way to reduce the impact of history records is to regularly create baselines of modules. When you create a baseline, the history is removed from the module and stored in the baseline. As a result, the time that is required to load the module is reduced. For more information, see Baselines.

Shareable edits in modules

You can create separate sections in a module and grant users different types of access to those sections. Team members can open a module and lock one section for editing. Other team members can edit other sections in the module simultaneously. Each section is controlled by a separate file in the database that must be loaded when you open the module. For better performance, do not create a section for every object in the module. Reduce the number of sections by aggregating groups of objects into sections by object hierarchy or subject matter. For more information, see Creating editable sections in modules.

Default views

When you save a private or public view, you can create a default view that becomes the template for other private or public views. When you create a default view, avoid the use of layout DXL columns or traceability columns. If those columns contain links to modules that must open when you open the module, performance might decrease. The values that are stored in layout DXL columns are recalculated every time that the display is refreshed.

If you do not need the DXL program to dynamically update, you can convert the contents of the layout DXL column to attribute DXL. If you must include layout columns in the default view, you can show all depths of traceability in the same column. You can also improve performance by excluding the module explorer from the default view. For more information, see Saving views and Converting layout DXL to attribute DXL.

Deleted artifacts

When you delete a project, folder, or module, the artifact is not actually removed from the database. To improve performance, you can permanently remove artifacts by purging deleted items in the database explorer. For more information, see Deleting, undeleting, and purging.

Module size and OLEs

The size of a module is affected by the number of objects, attributes, and OLE objects that are in the module. If module size begins to slow performance, move some content to a new module. When you load a module, the OLE objects in the module are also loaded into the memory. If the number and size of the OLEs are large, you might see delays when you open, scroll, or close a module.

By default, changes to OLEs are not recorded in the attribute history. If you modify the OLE history setting in the database properties window, you might slow performance. For more information, see Recording history for OLE objects.

DXL triggers and scripts

In DXL, you can include triggers, which are scripts that are run when certain operations are performed in Rational DOORS, such as opening or closing a module. To improve performance, reduce the number of triggers.

Avoid the use of strings in DXL scripts. Instead, use buffers, which can be deleted when they are no longer used. For more information, see Extending Rational DOORS with DXL.


Feedback