Rational DOORS 데이터베이스 및 클라이언트를 위한 성능 조정

하드웨어 구성 및 요구사항 관리 아티팩트와 프로세스를 변경하여 IBM® Rational® DOORS® 데이터베이스 및 클라이언트의 성능을 향상시킬 수 있습니다.
다음 영역에서 데이터베이스 및 클라이언트의 성능을 향상시킬 수 있습니다.

서버 및 네트워크

Rational DOORS 데이터베이스는 파일 기반 핸들링을 수행하는 단일 스레드 서버입니다. 하드웨어가 허용하면 서버는 초당 수백 건의 조작을 완료할 수 있지만 한 번에 하나의 파일만 처리됩니다. 클라이언트에서 서버까지 네트워크의 거리가 성능에 영향을 줄 수 있습니다. 네트워크 스토리지의 경우 SAN(Storage Area Network) 솔루션은 지원되지만 NAS(Network Attached Storage)는 지원되지 않습니다.

성능을 향상시키려면 다음을 수행하십시오.
  • 데이터베이스 서버에서 디스크 속도와 프로세서 속도를 최대화하십시오.
  • 클라이언트에서 서버까지 네트워크의 거리를 줄이십시오. 합당한 성능을 위해서는 Ping 시간이 50밀리초 미만이어야 합니다. Ping 시간이 50밀리초를 넘는 경우 Citrix 가상화를 사용하여 성능을 향상시킬 수 있습니다.
  • Rational DOORS Web Access를 사용 중인 경우는 네트워크에서 데이터베이스 서버 근처에 있는 상호 운용 서버를 찾으십시오.

메모리

데이터베이스 서버는 일반적인 메모리 요구사항을 갖습니다. 2GB의 RAM이면 대부분 프로젝트에 충분합니다. 그러나 Rational DOORS가 문서 기반 애플리케이션이므로 모듈을 열 때 모듈에 있는 모든 데이터가 메모리에 로드됩니다. 모듈에 다른 모듈에 대한 링크가 있으면 이러한 모듈이 백그라운드로 로드됩니다. 다른 모듈에 대한 많은 링크와 다수의 오브젝트가 있는 대형 모듈일 경우 메모리 소비량은 크게 늘어날 수 있습니다. 모듈 내보내기 조작과 Rational DOORS eXtension Language(DXL) 처리 역시 메모리를 소비하며 성능을 늦출 수 있습니다.

Rational DOORS 버전 9.5 및 이상에 대한 데스크탑 클라이언트는 LAA(Large Address Aware) 메모리 관리를 지원합니다. LAA를 통해 32비트 시스템의 3GB 메모리와 64비트 시스템의 4GB 메모리로 클라이언트의 가상 주소 공간을 늘릴 수 있습니다. LAA로 메모리 구성에 대한 자세한 정보는 Rational DOORS 클라이언트 설치를 참조하십시오.

Rational DOORS 버전 9.5.1 및 이상에는 메모리 소비를 줄이는 메모리 최적화가 포함되어 있습니다. Rational DOORS 버전 9.6.0 및 이상은 사용 가능한 메모리 양을 늘려주는 64비트 클라이언트가 포함되어 있습니다.

히스토리 및 기준선

모듈의 활동 레코드는 히스토리 파일에 저장됩니다. 팀 구성원이 오브젝트 컨텐츠와 링크를 추가할 때마다 모듈 히스토리가 늘어나며 모듈을 열 때 메모리에 로드됩니다. 성능 저하를 피하기 위해 특정 모듈 및 오브젝트 속성에 대한 구성을 설정하여 저장된 히스토리 양을 줄일 수 있습니다. 히스토리 레코드의 영향을 줄이는 쉬운 방법은 정기적으로 모듈의 기준선을 작성하는 것입니다. 기준선을 작성할 때 모듈에서 히스토리가 제거되며 기준선에 저장됩니다. 결과적으로 모듈을 로드하는 데 필요한 시간이 줄어듭니다. 자세한 정보는 기준선의 내용을 참조하십시오.

모듈에서 공유 가능한 편집

모듈에서 별도 섹션을 작성하고 이러한 섹션에 대해 다양한 유형의 액세스 권한을 사용자에게 부여할 수 있습니다. 팀 구성원은 모듈을 열고 편집을 위해 한 섹션을 잠글 수 있습니다. 다른 팀 구성원은 모듈에서 동시에 다른 섹션을 편집할 수 있습니다. 각 섹션은 모듈을 열 때 로드되어야 하는 데이터베이스에 있는 별도의 파일로 제어됩니다. 더 나은 성능을 위해 모듈의 모든 오브젝트에 대해 섹션을 작성하지 마십시오. 오브젝트 계층 구조나 주제에 따라 오브젝트 그룹을 섹션으로 집합하여 섹션 수를 줄이십시오. 자세한 정보는 모듈의 편집 가능한 섹션 작성을 참조하십시오.

기본 보기

개인용 보기 또는 공용 보기를 저장할 때 기타 개인용 또는 공용 보기를 위한 템플리트가 되는 기본 보기를 작성할 수 있습니다. 기본 보기를 작성할 때 레이아웃 DXL 열이나 추적성 열을 사용하지 마십시오. 이러한 열에 모듈을 열 때 열어야 하는 모듈에 대한 링크가 포함되면 성능이 저하될 수 있습니다. 레이아웃 DXL 열에 저장된 값은 표시가 새로 고쳐질 때마다 다시 계산됩니다.

동적으로 업데이트하기 위해 DXL 프로그램이 필요하지 않으면 레이아웃 DXL 열의 컨텐츠를 속성 DXL로 변환할 수 있습니다. 기본 보기에 레이아웃 열을 포함해야 하는 경우 동일한 열에 모든 수준의 추적성을 표시할 수 있습니다. 또한 기본 보기에서 모듈 탐색기를 제외하여 성능을 향상할 수 있습니다. 자세한 정보는 보기 저장레이아웃 DXL을 속성 DXL로 변환을 참조하십시오.

삭제된 아티팩트

프로젝트, 폴더 또는 모듈을 삭제할 때 아티팩트가 데이터베이스에서 실제로 제거되지 않습니다. 성능을 개선하기 위해 데이터베이스 탐색기에서 삭제된 항목을 영구 제거하여 아티팩트를 영구적으로 제거할 수 있습니다. 자세한 정보는 삭제, 삭제 취소, 영구 제거를 참조하십시오.

모듈 크기 및 OLE

모듈의 크기는 모듈에 있는 오브젝트, 속성, OLE 오브젝트 수의 영향을 받습니다. 모듈 크기가 성능을 늦추기 시작하면 일부 컨텐츠를 새 모듈로 옮기십시오. 모듈을 로드할 때 모듈에 있는 OLE 오브젝트도 메모리에 로드됩니다. OLE의 수 및 크기가 큰 경우 모듈을 열거나 스크롤하거나 닫을 때 지연되는 것을 볼 수 있습니다.

기본적으로 OLE에 대한 변경은 속성 히스토리에 기록되지 않습니다. 데이터베이스 특성 창에서 OLE 히스토리 설정을 수정하면 성능이 느려질 수 있습니다. 자세한 정보는 OLE 오브젝트에 대한 히스토리 레코딩을 참조하십시오.

DXL 트리거 및 스크립트

DXL에서 모듈 열기 및 닫기와 같이 Rational DOORS에서 특정 조작이 수행될 때 실행되는 스크립트인 트리거를 포함할 수 있습니다. 성능을 향상시키려면 트리거 수를 줄이십시오.

DXL 스크립트에서 문자열 사용을 피하십시오. 그 대신 더 이상 사용되지 않을 때 삭제할 수 있는 버퍼를 사용하십시오. 자세한 정보는 DXL로 Rational DOORS 확장을 참조하십시오.


피드백