La base de données Rational DOORS est un serveur à unité d'exécution unique qui effectue le traitement basé sur fichier. Si le matériel le permet, le serveur peut accomplir des centaines d'opérations par seconde, mais un seul fichier est traité à la fois. La distance sur le réseau du client au serveur peut affecter les performances. Pour le stockage réseau, la solution de réseau d'unités de stockage (SAN) est prise en charge, mais celle de serveur d'accès au réseau (NAS) ne l'est pas.
Le serveur de base de données possède des exigences de mémoire modestes : 2 Go de RAM suffisent pour la plupart des projets. Cependant, Rational DOORS étant une application basée sur document, lorsque vous ouvrez un module, toutes ses données sont chargées dans la mémoire. Si le module contient des liens vers d'autres modules, ceux-ci sont chargés en arrière-plan. Si vous possédez de grands modules contenant de nombreux objets et liens vers d'autres modules, l'utilisation de la mémoire peut augmenter de façon significative. Les opérations d'exportation de module et de traitement Rational DOORS eXtension Language (DXL) consomment également de la mémoire et peuvent ralentir les performances.
Le client bureautique pour Rational DOORS version 9.5 et ultérieures prend en charge la gestion de mémoire Large Address Aware (LAA). Avec le LAA, vous pouvez augmenter l'espace adresse virtuel du client à 3 Go de mémoire sur les systèmes 32 bits et 4 Go sur les systèmes 64 bits. Pour plus d'informations sur la configuration de la mémoire avec le LAA, voir Installation du client Rational DOORS.
Rational DOORS version 9.5.1 et ultérieures comprend une optimisation de la mémoire qui réduit la consommation de mémoire. Rational DOORS version 9.6.0 et ultérieures comprend un client 64 bits, ce qui augmente la quantité de mémoire disponible.
L'enregistrement de l'activité dans un module est stockée dans un fichier historique. L'historique de module, qui s'agrandit au fur et à mesure que les membres d'équipe ajoutent du contenu d'objet et des liens, est chargé dans la mémoire lorsque vous ouvrez le module. Pour éviter le ralentissement des performances, vous pouvez réduire la quantité d'historique enregistrée en définissant des configurations pour des attributs de module et d'objet particuliers. Un moyen simple de réduire l'impact des enregistrements d'historique consiste à créer régulièrement des bases de référence de modules. Lorsque vous créez une base de référence, l'historique est supprimé du module et stocké dans la base de référence. Ainsi, le temps de chargement du module est réduit. Pour plus d'informations, voir Versions de référence.
Lorsque vous enregistrez une vue publique ou privée, vous pouvez créer une vue par défaut qui devient le modèle pour d'autres vues publiques ou privées. Lorsque vous créez une vue par défaut, évitez d'utiliser les colonnes DXL d'agencement ou les colonnes de traçabilité. Si ces colonnes contiennent des liens vers des modules qui doivent s'ouvrir lorsque vous ouvrez le module, les performances peuvent diminuer. Les valeurs stockées dans les colonnes DXL d'agencement sont recalculées à chaque actualisation de l'affichage.
Si vous n'avez pas besoin que le programme DXL se mette à jour dynamiquement, vous pouvez convertir le contenu de la colonne DXL d'agencement en DXL d'attribut. Si vous devez inclure des colonnes d'agencement dans la vue par défaut, vous pouvez afficher toutes les profondeurs de traçabilité dans la même colonne. Vous pouvez également améliorer les performances en excluant l'explorateur de module de la vue par défaut. Pour plus d'informations, voir Enregistrement de vues et Conversion de DXL d'agencement en DXL d'attribut.
Lorsque vous supprimez un projet, dossier ou module, l'artefact n'est pas réellement supprimé de la base de données. Pour améliorer les performances, vous pouvez supprimer des artefacts de façon permanente en purgeant les éléments supprimés dans l'explorateur de base de données. Pour plus d'informations, voir Suppression, annulation de suppression et purge.
La taille d'un module est affectée par le nombre d'objets, d'attributs et d'objets OLE qui sont dans le module. Si la taille du module commence à ralentir les performances, déplacez du contenu vers un nouveau module. Lorsque vous chargez un module, les objets OLE qu'il contient sont également chargés dans la mémoire. Si le nombre et la taille des OLE sont importants, vous pouvez remarquer des retards lorsque vous ouvrez, parcourez ou fermez un module.
Par défaut, les modifications apportées aux OLE ne sont pas enregistrées dans l'historique d'attribut. Si vous modifiez le paramètre d'historique OLE dans la fenêtre des propriétés de base de données, vous risquez de ralentir les performances. Pour plus d'informations, voir Enregistrement de l'historique pour des objets OLE.
Pour améliorer les performances, réduisez le nombre de modules de liens en regroupant des types communs de liens dans le même module de liens. Lorsque vous ajoutez une colonne de traçabilité ou effectuez une analyse de lien dans un module, réduisez la profondeur de l'analyse pour réduire le nombre de modules ouverts. Pour plus d'informations, voir Modules de liens, ensembles de liens et appariement d'ensembles de liens et Ajout d'une colonne de traçabilité.
Dans DXL, vous pouvez inclure des déclencheurs, qui sont des scripts que vous exécutez lorsque certaines opérations sont effectuées dans Rational DOORS, telles que l'ouverture ou la fermeture d'un module. Pour améliorer les performances, réduisez le nombre de déclencheurs.
Evitez d'utiliser des chaînes dans les scripts DXL. Au lieu de cela, utilisez des mémoires tampon, qui peuvent être supprimées lorsqu'elles ne sont plus utilisées. Pour plus d'informations, voir Extension de Rational DOORS avec DXL.