확장 가능한 구성 요소 개발

COM 구성 요소 내부에 대부분의 비즈니스 논리를 캡슐화해야 하므로 성능이 뛰어나면서도 쉽게 확장할 수 있도록 구성 요소를 디자인하는 것이 중요합니다.

다음은 확장 가능한 구성 요소를 만드는 데 도움이 되는 제안 사항입니다.

알고리즘 최적화

구성 요소가 적절한 스레딩을 준수하도록 합니다. 페이지 영역 구성 요소는 아파트 스레드 모델이나 양쪽 스레드 모델 중 하나를 사용해야 하며 응용 프로그램 영역 구성 요소는 양쪽 스레드 모델을 사용하고 free-threaded marshaller를 모아야 합니다. 구성 요소 스레드 문제에 대한 자세한 내용은 Platform SDK에 있는 IIS 문서에서 스레드 모델 선택을 참조하십시오.
구성 요소가 집약적으로 힙을 사용하는 경우에는 다른 힙 대안을 고려합니다. Windows^® 힙의 집약적인 사용으로 자원 경합이 일어날 수 있습니다. 다음과 같은 여러 가지 메모리 할당 대체 방안을 강구합니다.
- 힙 파티션 - 기본 프로세스 힙 외에 복수 사용자 지정 힙 작성을 통해 수행합니다. 그러면 각 사용자 지정 힙은 독립적인 비전역 잠금에 의해 제어되어 잠금 경합이 줄어듭니다.
- 캐시된 할당 - 개체 사용자와 힙 사이의 중간 층에서 작동하는 사용자 지정 할당 작업을 사용하여 만듭니다. Win32 힙은 자주 호출되지 않고 크기가 큰 메모리 블록에 대해서만 호출됩니다. 이들 블록은 사용자 지정 할당기에 의해 나눠지고 관리됩니다.
- 스택 할당 - C 런타임 함수 _alloca를 사용하여 힙 대신에 스택에 개체에 대한 메모리를 할당합니다.사용할 수 있는 스택 공간이 제한되어 있기 때문에 이 방법은 비교적 작은 개체에만 사용할 수 있습니다. 또한 새로 할당된 개체는 현재 함수 내에서나 현재 함수에 의해 호출된 함수 내에서만 사용할 수 있습니다. 현재 함수가 반환되면 스택에 할당된 저장 공간은 없어집니다.
- 개체 캡슐화 - 버퍼를 구성 요소 클래스의 구성원 데이터 구조로 결합하여 수행합니다.이 버퍼는 Win32 힙에 액세스해야 하는 작업에 사용됩니다.
구성 요소 내에서 전역 잠금을 사용하지 않습니다. 전역 잠금을 사용하면 종종 거꾸로 구성 요소의 확장성에 영향을 줄 수 있습니다.
구성 요소를 응용 프로그램의 일부로 실행하고 있는 경우에는 응용 프로그램 디버깅을 위한 독립 프로세스로 응용 프로그램을 지정합니다. IIS 4.0에 도입된 프로세스 격리는 유용한 기능입니다. 그러나 프로세스 격리를 지원하기 위해 요구되는 교차 프로세스 마샬링은 구성 요소 실행에 어느 정도의 오버헤드를 초래할 수 있습니다. 오버 헤드에서 이런 차이는 단순한 구성 요소에서는 가장 중요한 사항이지만 더 복잡한 구성 요소에서는 그다지 문제가 되지 않습니다. 확장성과 성능을 최대화하기 위해서는 응용 프로그램이 충분히 디버그되고 IIS에서 종속 프로세스로 실행할 수 있을 만큼 안정될 때까지 out-of-process로 실행하는 방안을 고려할 수 있습니다.
라이브러리 (in-process) COM+ 응용 프로그램에 구성 요소를 두는 방안을 고려합니다. 구성 요소 서비스의 Just-In-Time 활성 기능의 일부로 구성 요소의 COM 클래스 팩토리가 캐시되고 CreateInstance를 사용하여 각 인스턴스 작성 요청에 다시 사용됩니다.