SharePoint Server 2010의 워크플로에 대한 성능 및 용량 계획 예상

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 성능 및 용량 계획 문서에서는 워크플로 사용 시 Microsoft SharePoint Server 2010을 실행하는 토폴로지에 주는 영향에 대한 지침을 제공합니다.

SharePoint Server 2010의 용량 계획에 대한 일반 정보는 성능 및 용량 관리(SharePoint Server 2010)를 참조하십시오.

목차

• 테스트 팜 특성

• 테스트 결과

• 권장 사항

• 문제 해결

테스트 팜 특성

다음 섹션에서는 테스트 팜의 특성에 대해 설명합니다.

• 데이터 집합

• 작업량

• 하드웨어, 설정 및 토폴로지

데이터 집합

벤치마킹을 위해 대부분의 테스트는 팜에서 단일 사이트 모음에 있는 기본 팀 사이트에 대해 실행됩니다. 이 문서에서 소개하는 수동 시작 테스트는 8천 개의 항목이 있는 목록을 사용하여 워크플로를 시작했습니다.

작업량

이 시나리오에 대한 테스트는 다음과 같은 변수가 변경될 때 다양한 팜 구성이 어떻게 반응하는지 예측할 수 있도록 합니다.

• 프런트 엔드 서버의 수가 여러 컴퓨터에서 선언적 워크플로를 수동으로 시작하기 위한 처리량에 주는 영향

• 프런트 엔드 서버의 수가 여러 컴퓨터에서 항목을 만들 때 선언적 워크플로를 자동으로 시작하기 위한 처리량에 주는 영향

• 프런트 엔드 서버의 수가 여러 컴퓨터에서 작업을 완료하기 위한 처리량에 주는 영향

이 문서에 나와 있는 구체적인 용량 및 성능 수치는 실제 환경의 수치와 다릅니다. 이 문서에 나와 있는 수치는 적절한 규모의 환경을 디자인하기 위한 시작점을 제공하기 위한 것입니다. 초기 시스템 디자인을 완료한 후 구성을 테스트하여 시스템이 사용자 환경의 여러 요소를 지원하는지 여부를 확인하십시오.

이 섹션에서는 테스트 시나리오를 정의하고 각 시나리오에 사용된 테스트 프로세스에 대해 설명합니다. 테스트 결과 및 특정 매개 변수와 같은 자세한 정보는 이 문서 뒷부분에 있는 각 테스트 결과 섹션에서 제공됩니다.

하드웨어, 설정 및 토폴로지

이러한 테스트에 사용된 토폴로지에서는 콘텐츠 데이터베이스용 컴퓨터 한 대와, SharePoint Server 2010이 기본 설치된 1~4대의 프런트 엔드 컴퓨터가 사용됩니다. 이러한 테스트에서 사용된 워크플로를 Microsoft SharePoint Foundation 2010에서 사용할 수는 없지만, 해당 결과를 통해 이러한 배포에 대한 유사한 시나리오를 예측할 수 있습니다. 이 테스트에 사용된 데이터 집합은 콘텐츠 데이터베이스 한 개의 팀 사이트 서식 파일을 기반으로 하는 단일 사이트가 포함된 사이트 모음 하나를 포함합니다.

자세한 테스트 결과를 제공하기 위해 테스트에 여러 가지 팜 구성이 사용되었습니다. 팜 구성은 1~4대의 웹 서버와 Microsoft SQL Server 2008을 실행하는 컴퓨터 한 대로 이루어집니다. 테스트는 클라이언트 컴퓨터 한 대를 사용하여 수행되었습니다. 데이터베이스 서버 및 모든 웹 서버는 64비트였으며 클라이언트 컴퓨터는 32비트였습니다.

다음 표에는 테스트에 사용된 하드웨어가 나와 있습니다.

워크플로 용량 계획 토폴로지

테스트 결과

다음 표에서는 SharePoint Server 2010의 워크플로에 대한 테스트 결과를 보여 줍니다. 각 테스트 그룹에서 일부 특정 변수만 변경하여 팜 성능에 미치는 점진적인 영향을 보여 줍니다.

이 문서에서 보고되는 모든 테스트는 인지 시간, 즉 연속적인 작업 사이의 자연스러운 지연 없이 수행되었습니다. 실제 환경에서는 각 작업 이후에 사용자가 작업의 다음 단계를 수행할 때 약간의 지연이 있게 됩니다. 반면에 이 테스트에서는 각 작업이 수행된 후 바로 다음 작업이 이어지므로 팜에 연속적으로 부하가 발생합니다. 이러한 부하로 인해 성능에 부정적인 영향을 미칠 수 있는 데이터베이스 경합 및 기타 요인이 발생할 수 있습니다.

웹 서버 확장이 처리량에 주는 영향

다음의 처리량 테스트는 SharePoint Server 2010에 포함된 승인 워크플로를 사용하여 실행되었습니다. 워크플로 연결을 통해 하나의 작업이 할당되며, 모든 인스턴스는 단일 목록에서 실행됩니다. 이 워크플로의 각 인스턴스는 콘텐츠 데이터베이스에 다음 항목을 만듭니다.

• 워크플로 상태를 저장하기 위한 Workflows 테이블의 항목

• 보조 목록 항목 5개(1개 작업 및 4개 기록 항목)

• 워크플로의 상위 항목과 작업에 대한 이벤트를 처리하는 4개 이벤트 수신기

워크플로 작업이 대기 상태가 되지 않도록 워크플로 연기 임계값은 매우 크게 설정됩니다. 각 테스트는 5분 동안 실행했으며 5분 동안 실행되었습니다.

수동 시작 처리량

다음 표의 테스트에서는 프런트 엔드 서버를 추가하는 경우 웹 서비스를 통해 워크플로를 동기적으로 시작하는 처리량에 어떤 영향을 주는지를 보여 줍니다. 이 테스트는 25명의 사용자가 동시에 Workflow.asmx에서 StartWorkflow 메서드를 지속적으로 호출하는 사용자 부하를 사용하여 실행되었으며, 팜에서 다른 부하는 없었습니다. 웹 요청 삭제가 수행될 때까지 사용자 부하는 최적 상태였습니다. 목록에는 최대 8,000개의 항목이 채워집니다.

다음 그래프는 처리량의 변화를 보여 줍니다. 프런트 엔드 서버가 추가되어도 팜 처리량 선 자체에는 영향을 주지는 않지만, 프런트 엔드 서버가 3~4대일 때 처리량이 가장 높아집니다. 즉, 워크플로를 수동으로 시작하기 위한 최대 처리량은 초당 약 30개 워크플로이며, 프런트 엔드 서버를 5대 이상 추가하는 경우의 영향은 미미합니다.

수동 시작 처리량

항목을 만들 때의 워크플로 자동 시작 처리량

다음 표의 테스트에서는 프런트 엔드 서버를 추가하는 경우 항목을 만들 때 워크플로를 자동으로 시작하는 처리량에 어떤 영향을 주는지를 보여 줍니다. 이 테스트는 150명의 사용자가 동시에 목록 웹 서비스를 지속적으로 호출하여 단일 목록에서 새 목록 항목을 만드는 사용자 부하를 사용하여 실행되었으며, 서버에서 다른 작업은 수행되지 않았습니다. 목록은 빈 목록으로 시작되었습니다.

다음 그래프는 처리량의 변화를 보여 줍니다. 처리량은 수동 시작 작업 시와 매우 가깝습니다. 수동 시작 테스트와 마찬가지로, 처리량은 프런트 엔드 서버가 약 3~4대일 때 최대 초당 약 32개 워크플로로 가장 높았습니다. 프런트 엔드 서버를 3~4대보다 많이 추가하는 경우의 영향은 미미합니다.

자동 시작 워크플로 처리량

작업 완료 처리량

다음 표의 테스트에서는 프런트 엔드 서버를 추가하는 경우 워크프롤 작업을 완료하는 처리량에 어떤 영향을 주는지를 보여 줍니다. 이전 테스트의 자동 시작 워크플로에서 사용된 작업 목록을 사용하여 작업을 완료했습니다. 이 테스트는 25명의 사용자가 동시에 Workflow.asmx에서 AlterToDo 메서드를 지속적으로 호출하는 사용자 부하를 사용하여 실행되었으며, 서버에서 다른 작업은 수행되지 않았습니다. 목록은 빈 목록으로 시작되었습니다.

다음 그래프는 처리량의 변화를 보여 줍니다. 수동 시작 테스트와 마찬가지로, 처리량은 프런트 엔드 서버가 약 3~4대일 때 최대 초당 약 32개의 워크플로로 가장 높았습니다. 프런트 엔드 서버를 4대 이상 추가하는 경우의 영향은 미미합니다.

작업 완료 처리량

워크플로 인스턴스의 목록 크기와 수가 처리량에 주는 영향

다음 표의 테스트에서는 워크플로의 목록 크기가 커지고 워크플로 수가 많아지는 경우 처리량이 어떻게 변화하는지를 보여 줍니다. 목록에서 1백만 개의 항목이 만들어질 때까지 자동 시작 워크플로 테스트를 지속적으로 실행하여 데이터 채우기를 수행하며, 테스트 전체의 서로 다른 검사점에서 테스트를 중지하여 핵심 처리량 테스트에서 수행했던 것과 같이 처리량 측정을 수행합니다. 테스트는 4x1 토폴로지에서 수행되었습니다.

데이터 채우기 중에 안정성을 유지하기 위해, 데이터베이스 서버에서 최대 연결 수에 도달하지 않도록 워크플로 대기를 설정해 두어야 합니다. 연결을 사용할 수 없으며 워크플로 작업에서 콘텐츠 데이터베이스에 연결할 수 없는 경우에는 작업을 실행할 수 없습니다. 워크플로 대기에 대한 자세한 내용은 권장 사항을 참조하십시오.

항목 및 워크플로 수가 많아지는 경우의 자동 시작 처리량

단일 목록과 단일 작업 및 기록 목록의 경우 항목 1,000개의 100,000개 사이에서는 처리량이 꾸준히 감소했습니다. 그러나 이 지점이 지난 후에는 감소 속도가 줄어들었습니다. 처리량이 줄어드는 데는 다양한 요인이 있습니다.

이러한 요인 중 하나는 인스턴스별로 콘텐츠 데이터베이스의 여러 테이블에 추가되는 행의 수입니다. 앞서 설명한 것처럼, 워크플로는 여러 목록 항목뿐 아니라 각 워크플로 인스턴스가 등록하는 이벤트 수신기도 만듭니다. 서로 다른 여러 범위에서 테이블 크기가 커질수록 행 추가 속도는 느려지고, 이와 같은 추가 작업의 집계 속도 저하는 목록 항목을 만들 때만 나타나는 속도 저하의 폭보다 더 큽니다.

작업 목록 크기도 추가적인 오버헤드를 생성합니다. 새 목록과 새 작업 목록에 대해 실행되는 워크플로의 처리량을 비교할 때, 작업 목록의 성능에 대한 영향이 더 큽니다. 이는 상위 목록 항목에 비해 작업 목록이 더 많은 이벤트 수신기를 등록하기 때문입니다. 다음 차트에 그 차이가 설명되어 있습니다.

큰 목록에 대해 많은 워크플로를 실행할 예정이며, 테스트에서 나타난 것보다 높은 처리량이 필요한 경우에는 워크플로 연결 간에 작업 목록을 분할할 수 있는지를 고려하십시오.

권장 사항

이 섹션에서는 성능 및 용량에 대한 일반적인 권장 사항을 설명합니다. 이러한 권장 사항을 참조하여 작성된 시작 토폴로지의 용량 및 성능 특징을 파악하고 시작 토폴로지의 수평 또는 수직 확장 여부를 결정할 수 있습니다.

최소 및 권장 시스템 요구 사항에 대한 구체적인 정보는 하드웨어 및 소프트웨어 요구 사항(SharePoint Server 2010)을 참조하십시오.

수평 확장된 토폴로지

최대 4대의 웹 서버를 포함하도록 토폴로지를 수평 확장하여 워크플로 처리량을 높일 수 있습니다. 4대보다 많은 웹 서버를 추가하는 경우의 처리량 증가는 미미합니다. 성능 관련 워크플로 설정을 통해 워크플로 처리량을 제한할 수 있습니다. 워크플로 대기 및 성능 관련 설정에서 이러한 설정에 대해 보다 자세하게 설명합니다.

처리량 목표 예측

사용자 수, 사용자 작업의 유형/복잡도/빈도 등의 다양한 요인이 처리량에 영향을 줄 수 있습니다. 콘텐츠 데이터베이스에 대해 많은 작업을 수행하거나 더 많은 이벤트를 등록하는 복잡한 워크플로일수록 다른 워크플로에 비해 실행 속도는 더 느리며 많은 리소스를 사용합니다.

이 테스트에 사용된 워크플로는 작업 활동에 기본적으로 제공되는 콘텐츠 데이터베이스에 여러 항목을 만듭니다. 워크플로의 작업 수가 적은 경우에는 이와 유사한 처리량 특성을 기대할 수 있습니다. 대부분의 워크플로에 매우 간단한 작업만 포함되는 경우에는 처리량이 높아질 수 있습니다. 워크플로가 많은 작업으로 구성되거나 집중적인 백 엔드 작업 또는 처리 기능을 필요로 하는 경우에는 처리량이 줄어들 수 있습니다.

워크플로에서 수행할 작업을 이해하는 것 외에도, 워크플로가 실행되는 위치가 워크플로가 큰 목록에 대해 실행되는지 여부(이 경우 시간이 지남에 따라 처리량이 낮아짐)를 고려하십시오.

SharePoint Server 2010은 다양한 방식으로 배포 및 구성할 수 있습니다. 따라서 지정된 수의 서버에서 지원할 수 있는 사용자 수를 예측할 수 있는 간단한 방법은 없습니다. 그러므로 프로덕션 환경에서 SharePoint Server 2010을 배포하기 전에 자신의 환경에서 테스트를 수행하십시오.

워크플로 대기 및 성능 관련 설정

워크플로에서는 대기 시스템을 사용하여 팜 리소스 및 콘텐츠 데이터베이스에서 워크플로 관련 부담을 제어합니다. 이 시스템을 사용하는 경우 한 데이터베이스에 대해 실행되는 워크플로 수가 관리자가 구성한 임계값에 도달할 때 후속 워크플로 작업이 워크플로 타이머 서비스를 통해 실행되도록 큐에 추가됩니다. 기본적으로 이 서비스는 매분마다 타이머 작업을 통해 워크플로 작업 항목의 일괄 처리를 받습니다.

대기 메커니즘과 직간접적으로 관련된 여러 팜 관리자 설정이 워크플로의 확장 및 성능에 영향을 줍니다. 다음 섹션에서는 이러한 설정의 용도와, 성능 요구 사항을 충족하기 위해 설정을 조정하는 방법에 대해 설명합니다.

기본 큐 설정 이해

팜 관리자는 다음 설정을 조정하여 대기 시스템의 기본 특성을 구성할 수 있습니다.

• 워크플로 연기 임계값(WorkflowPostponeThreshold <정수>)

  추가 요청 및 작업이 대기 상태가 될 때까지 단일 콘텐츠 데이터베이스에 대해 실행할 수 있는 최대 워크플로 수입니다. 대기 중인 워크플로는 시작 중 상태로 표시됩니다. 이 팜 전체 설정의 기본값은 15이며, 이는 진행할 수 있는 최대 워크플로 수가 아니라 한 번에 처리되는 워크플로 작업 수를 나타냅니다. 워크플로 작업이 완료되면 후속 작업을 실행할 수 있습니다.

• Workflow 이벤트 전달 일괄 처리 크기(Set-SPWorkflow –BatchSize <정수>)

  워크플로 타이머 서비스는 연기 임계값 제한의 예외로, 큐에서 항목 일괄 처리를 검색한 다음 한 번에 하나씩 실행합니다. 이러한 일괄 처리는 연기 임계값보다 클 수 있습니다. 실행당 서비스가 받는 작업 항목의 수는 BatchSize 속성을 사용하여 설정됩니다. BatchSize 속성은 서비스 인스턴스별로 한 번 설정할 수 있으며, 기본값은 100입니다. 프런트 엔드 서버로 사용되도록 구성되지 않은 응용 프로그램 서버에서 실행할 때, 워크플로 타이머 서비스에서는 Web.config의 워크플로 구성 설정을 구성 데이터베이스에서 설정해야 합니다. 이 작업을 수행하려면 SPWebApplication 개체에서 UpdateWorkflowConfigurationSettings()를 호출하는 스크립트를 사용해야 하는데, 이 스크립트는 프런트 엔드 서버에서 Web.config 설정을 복사합니다.

• 워크플로 타이머 작업 빈도(Set-SPTimerJob job-workflow –schedule <문자열>)

  워크플로 타이머 서비스가 실행되는 빈도는 타이머 작업 설정을 통해 조정할 수 있습니다. 기본적으로 서비스는 5분마다 실행되도록 설정됩니다. 즉, 큐 맨 위의 작업 항목이 처리될 때까지 5분이 지연될 수 있습니다.

  참고

  작업 기한 만료와 같은 예약된 작업 항목도 동일한 타이머 메커니즘을 통해 선택됩니다. 따라서 이러한 항목 역시 동일한 시간 간격만큼 지연됩니다.

중앙 관리에서 공유 서비스 관리를 사용하여 각 서버에서 워크플로 타이머 서비스를 해제할 수 있습니다. 기본적으로 이 서비스는 팜의 모든 프런트 엔드 서버에서 실행됩니다. 각 작업은 모든 팜의 모든 콘텐츠 데이터베이스 및 웹 응용 프로그램에서 반복됩니다.

연기 임계값, 일괄 처리 크기 및 타이머 빈도를 조합해 사용하여 데이터베이스에 대한 워크플로 작업을 제한할 수 있습니다. 최대 처리량은 작업이 대기 상태가 되는 속도와 큐에서 처리되는 속도의 영향을 받습니다.

예를 들어 기본 설정, 단일 타이머 서비스 및 단일 콘텐츠 데이터베이스를 사용하는 경우 큐에 항목이 1,000개 있으면 이들 항목을 모두 실행하는 데 10개의 타이머 작업을 실행해야 하며, 실행 시간은 50분이 걸립니다. 그러나 일괄 처리 크기를 1,000으로 설정하고 타이머 작업이 매분마다 실행되도록 설정하는 경우에는 모든 작업의 실행이 1분 후에 시작됩니다. 연기 임계값을 더 높게 설정하는 경우에는 더 많은 작업이 동기적으로 실행되므로, 대기 상태가 되는 요청 수가 줄어들고 이러한 워크플로를 처리하는 데 필요한 총 시간이 짧아집니다.

프런트 엔드 서버에서 워크플로를 실행하지 않을 예정이며 작업을 즉시 실행하지 않아도 되는 경우에는 선택한 응용 프로그램 서버에서 워크플로 타이머 서비스가 실행되도록 분리하고, 연기 임계값을 매우 작은 숫자로 설정하여 워크플로가 일반적으로 타이머 서비스에서 실행되도록 강제로 지정하고, 일괄 처리 크기를 크게 설정하여 일괄 처리에서 항목을 더 빠르게 자주 받도록 설정하십시오. 워크플로가 시스템 전체에서 보다 동기적으로 실행되도록 하려면, 연기 임계값을 크게 설정하여 워크플로가 자주 연기되지 않고 보다 즉각적인 영향을 받을 수 있도록 하십시오.

워크플로를 작동할 방법에 가장 적합하도록 이러한 설정을 수정하십시오. 다양한 설정을 사용해 보고 테스트를 수행하여 현재 환경 및 요구 사항에 맞게 최적화하는 것이 좋습니다.

대기를 위한 설정 조정

오랜 시간 동안 팜에 많은 워크플로 부하가 지속적으로 적용되거나 시스템의 워크플로에서 많은 지연 이벤트가 대기 상태가 되는 경우에는 큐에 추가되는 워크플로 작업의 수가 늘어납니다. 이러한 경우에는 기본 큐 설정 외에, 큐를 정상 상태로 유지하기 위해 다음 설정을 조정해야 할 수 있습니다.

• 작업 항목 이벤트 전달 일괄 처리 크기

  워크플로에서 큐에 저장된 이벤트에 대해 사용하는 테이블은 SharePoint Server 2010의 워크플로가 아닌 다른 기능과 공유되는 일반 작업 항목 테이블입니다. 따라서 워크플로가 아닌 작업 항목을 큐에서 제거하는 다른 타이머 작업이 있습니다. 워크플로 이벤트 전달 일괄 처리 크기와 마찬가지로, 작업 항목 이벤트 전달 일괄 처리 크기는 한 번에 큐에서 제거되는 워크플로가 아닌 작업 항목의 수를 지정합니다.

• 워크플로 장애 조치 타이머 작업 빈도

  드물지만 워크플로 이벤트를 워크플로 인스턴스로 전달할 수 없는 경우에는 이벤트 전달이 큐에서 나중에 다시 시도할 장애 조치(failover) 작업 항목으로 예약됩니다(5분 후에 시작되며 다시 실패하는 경우 10분 후에, 그리고 20분 후에 계속적으로 다시 시작됨). 워크플로 장애 조치(failover) 타이머 작업은 장애 조치(failover) 작업 항목을 큐에서 제거하며, 이 설정은 장애 조치(failover) 타이머가 실행되는 빈도를 조정합니다. 기본적으로 이 타이머는 15분마다 실행됩니다.

• 워크플로 장애 조치 일괄 처리 크기

  워크플로 및 작업 항목 일괄 처리 크기 설정과 마찬가지로, 이 설정도 각 장애 조치(failover) 타이머 작업이 큐에서 제거할 장애 조치(failover) 이벤트의 수를 제어합니다.

  같은 테이블에서 많은 타이머 작업이 실행되므로, 큐에서 제거된 많은 항목으로 인해 데이터베이스 경합이 발생하고 처리량과 안정성이 낮아질 수 있습니다. 경합을 줄이려면 다음을 수행하는 것이 좋습니다.

  • 타이머 작업을 다음 타이머 작업이 시작되기 전에 완료할 수 있도록 일괄 처리 크기를 충분히 작게 또는 타이머 작업 빈도를 충분히 높게 설정하여 연기 임계값과 워크플로 배치 크기 간의 균형을 맞춥니다. 이렇게 하면 너무 많은 병렬 타이머 작업 실행을 구성하여 작업을 완료할 수 없는 현상을 방지할 수 있습니다.

  • 테이블 잠금을 방지하려면 두 일괄 처리 크기 설정을 5,000보다 크게 설정하지 마십시오.

작업 및 기록 목록의 확장 개선

워크플로는 인스턴스당 많은 수의 작업 및 기록 항목을 생성합니다. 기본적으로 이러한 목록은 쉽게 확장할 수 있도록 인덱싱되지만, 목록이 커질수록 성능은 항상 저하됩니다. 성능 저하 속도를 줄이려면 서로 다른 여러 워크플로 연결에 대해 항상 별도의 기록 및 작업 목록을 유지하고, 목록이 커짐에 따라 워크플로 연결 설정에서 주기적으로 이러한 목록을 변경하십시오.

워크플로에는 60일보다 전에 완료된 인스턴스의 작업 및 워크플로 인스턴스를 자동으로 삭제하는 일일 타이머 작업(job-workflow-autoclean)도 있습니다. 작업 목록 및 작업 목록의 이벤트를 최대한 깔끔하게 유지하려면 이 타이머 작업을 설정해 두십시오. 데이터를 보존해야 하는 경우에는 다른 목록이나 보관 위치에 데이터를 쓰십시오. 워크플로 기록 항목은 이 타이머 작업을 통해 삭제되지 않습니다. 이러한 항목을 정리해야 하는 경우에는 스크립트를 사용하거나 목록 사용자 인터페이스를 통해 수동으로 작업을 수행해야 합니다.

기타 고려 사항

목록에서 열을 제거하면 데이터베이스 작업이 목록의 항목 수에 비례하게 됩니다. 워크플로 연결을 제거하면 목록에서 워크플로 상태 열이 제거됩니다. 이로 인해 큰 목록의 경우 대규모 작업이 수행될 수 있습니다. 목록에 항목이 수백만 개와 같이 매우 많이 있는 경우에는 워크플로를 제거하는 대신 워크플로를 새 인스턴스 없음으로 설정하십시오.

문제 해결

웹 서버

다음 표에서는 팜의 웹 서버에 대해 모니터링할 성능 카운터와 프로세스를 보여 줍니다.

데이터베이스 서버

다음 표에서는 팜의 데이터베이스 서버에 대해 모니터링할 성능 카운터와 프로세스를 보여 줍니다.

See Also

Other Resources

Windows SharePoint Services 3.0의 워크플로 확장성 및 성능(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x412)(영문일 수 있음)