Project Online 성능 조정

몇 년 전 Project Online 출시하면서 모든 규모의 조직은 Office 365 클라우드 인프라의 편리성 내에서 Microsoft의 풍부한 PPM(프로젝트 포트폴리오 관리) 기능을 사용할 수 있었습니다.

클라우드 기반 서비스 사용의 명백한 이점 중 하나는 배포, 설정 및 하드웨어 및 소프트웨어 튜닝을 처리하지 않아도 되는 것이지만 조직이 Project Online 최상의 성능을 얻을 수 있도록 하기 위해 수행할 수 있는 몇 가지 단계가 여전히 있습니다.

Project Online 많은 구성 및 사용자 지정 설정을 제공하지만 사용자 지정은 성능에 영향을 미칠 수 있습니다. 이 문서에서는 가장 일반적인 Project Online 설정 중 일부의 성능 영향 및 장단점을 강조하여 Project Online 사용자 지정 및 구성과 관련하여 정보에 입각한 결정을 내릴 수 있습니다.

이 문서는 Office 365 프로젝트에 대한 네트워크 계획 및 성능 튜닝의 일부입니다.

Office 365 및 SharePoint Online 모범 사례

SharePoint Online 및 Office 365 대한 네트워크 계획 및 성능 조정에 대한 다양한 정보가 있습니다. 이 모든 정보는 Project Online 고객과 관련이 있으며 Project Online 관련된 다음 모범 사례 외에 협의해야 합니다.

구성 및 사용자 지정 Project Online

Project Web App 사이트의 많은 요소를 구성하고 사용자 지정할 수 있습니다. 관리 설정에서 사용 권한, 공동 작업 설정에서 모양과 느낌에 이르기까지 다양합니다. Project Web App 사이트의 전반적인 성능에 영향을 미칠 수 있는 설정을 살펴보겠습니다.

다음을 다룹니다.

• 보안 권한 모드

• Enterprise 프로젝트 형식

  • 프로젝트 사이트 구성

  • Project Online SharePoint Online 간의 동기화 메커니즘

• Active Directory 리소스 풀 동기화

• UI 사용자 지정 및 모양 및 느낌

• PDP(프로젝트 세부 정보 페이지) 및 워크플로

• 이벤트 처리

• OData 및 보고

• 할당량 Project Online

(이 정보 중 일부는 Project Server 2013 및 Project Server 2016 적용됩니다.)

사용 권한 모드: SharePoint 또는 프로젝트

Project Online 및 Project Server 2013에서는 레거시 프로젝트 사용 권한 모드가 아닌 SharePoint 권한 모드라는 새롭고 간소화된 권한 모델을 도입했습니다. 두 모드 간의 비교는 Technet에서 찾을 수 있습니다.

새 Project Online 인스턴스는 기본적으로 SharePoint 권한 모드로 프로비전되며, 이 모드는 대부분의 고객의 요구를 충족할 것이라고 확신합니다. 이 모드를 사용하면 일반 SharePoint 그룹 및 권한을 통해 사용자 권한 부여를 관리할 수 있습니다.

프로젝트 권한 모드는 높은 수준의 사용자 지정 기능을 제공하지만 성능 측면에서 가격이 책정 될 수 있습니다. 수백 개의 범주를 만들고 RBS(리소스 분석 구조)를 통해 동적 권한에 크게 의존하는 경우 관리자 및 포트폴리오 관리자와 같은 많은 콘텐츠에 액세스할 수 있는 사용자의 최종 사용자 환경이 느려질 수 있습니다.

참고

SharePoint 사용 권한 모드와 Project Server 사용 권한 모드 간을 전환하면 모든 보안 관련 설정이 삭제됩니다. SharePoint 사용 권한 모드에서 클래식 Project Server 권한 모드로 전환하는 경우 Project Server 2013에서 보안 권한 구조를 수동으로 구성하고 Project Server 2016. Project Server 사용 권한 모드에서 SharePoint 권한 모드로 다시 전환하면 Project Server 2013에서 보안 권한 정보가 삭제되고 Project Server 2016.

추천:

가능한 경우 전반적인 성능을 향상시키려면 기본 SharePoint 사용 권한 모드를 유지합니다. 프로젝트 권한 모드를 사용해야 하는 경우 사용자 지정을 가능한 한 제한합니다.

Enterprise 프로젝트 형식

EPT( Enterprise Project Types )는 단계, 단계, 단일 워크플로 및 PDP(프로젝트 세부 정보 페이지)를 캡슐화하는 래퍼를 나타냅니다.

또한 EPT를 사용하면 다음을 정의할 수 있습니다.

• 프로젝트 사이트 구성

• Project Online SharePoint Online 간의 동기화 메커니즘

프로젝트 사이트 구성

프로젝트 사이트는 핵심 SharePoint 기능을 기반으로 합니다. 프로젝트 사이트를 만드는 것은 간단한 프로세스가 아니며 조직에서 프로젝트 사이트가 필요할 수 있는지와 시기를 결정하는 것은 전체 최종 사용자 환경을 개선하는 데 큰 도움이 될 수 있습니다.

많은 조직에서 Project Online 사용하여 프로젝트 제안을 수집하고 평가한 후 자금을 지원할 프로젝트를 결정합니다. 프로젝트가 처음 게시될 때 프로젝트 사이트가 자동으로 만들어지도록 설정된 경우 모든 프로젝트 제안, 잘라내기를 하지 않는 프로젝트 제안도 프로젝트 사이트를 가져옵니다. 이러한 불필요한 사이트는 나중에 수동으로 정리해야 합니다.

프로젝트 사이트를 사용하기로 결정한 경우 사용자가 공동 작업 사이트를 만들 시기를 선택하거나 프로젝트 제안이 특정 단계 게이트에 도달하는 즉시 워크플로에서 만드는 것이 더 좋습니다.

현재 SharePoint Online은 각 사이트 모음에 대해 만들 수 있는 하위 사이트 수를 제한합니다. EPT를 사용하면 새 프로젝트 사이트를 만들 사이트 모음을 정의할 수 있습니다. 이렇게 하면 여러 사이트 모음에 걸쳐 있을 수 있으므로 각 프로젝트에 대한 프로젝트 사이트를 만들 수 있습니다.

예를 들어 IT 부서 전용 사이트 모음이 있는 경우 에서 프로젝트 사이트를 https://contoso.sharepoint.com/sites/IT 만들도록 IT 프로젝트 EPT를 구성할 수 있습니다.

추천:

조직에서 프로젝트 사이트를 사용하는 경우 자동으로 만드는 대신 요청 시 만드는 옵션을 선택합니다. 이렇게 하면 첫 번째 게시 환경의 속도가 빨라지고 불필요한 사이트와 콘텐츠가 생성되는 것을 방지할 수 있습니다.

각 EPT에 대해 다음을 통해 이 옵션을 구성할 수 있습니다.

1. Project Web App 설정에서 엔터프라이즈 프로젝트 형식을 클릭합니다.

2. 설정을 변경해야 하는 EPT를 선택합니다.

3. EPT 설정 페이지의 프로젝트 사이트 섹션에서 사용자가 선택할 수 있도록 허용을 선택합니다.

   

   EPT를 통해 자체 사이트 모음에 프로젝트 사이트를 만듭니다. 사이트 모음의 프로젝트 사이트 수를 SharePoint Online SharePoint Online 제한 이하로 유지합니다.

무엇을 동기화합니까?

Project Online SharePoint Server 위에서 Project Server를 실행하는 것과 동일한 방식으로 SharePoint Online 위에서 실행됩니다. 따라서 두 시스템 간에 특정 수의 구성 요소를 동기화해야 합니다. 이러한 동기화는 시간이 오래 걸릴 수 있으며 비즈니스 요구 사항에 따라 불필요할 수 있습니다. 이 문서에서는 필요한 동기화 시스템과 안전하게 끌 수 있는 동기화 시스템을 결정하는 데 도움이 되는 다양한 동기화 시스템을 모두 살펴봅니다. 이러한 설정 중 일부는 기본적으로 이미 꺼져 있습니다.

다음 섹션에서는 다음에 대해 설명합니다.

• 프로젝트 사이트에 대한 사용자 권한 동기화

• 엔터프라이즈 프로젝트에 대한 SharePoint 작업 목록 동기화

사용자 권한 동기화

프로젝트 사이트는 프로젝트 팀이 공동 작업하고, 문서를 업로드하고, 문제를 제기할 수 있는 작업 영역입니다. 동기화 사용자 권한이 켜져 있으면 사용자에게 프로젝트에 대한 권한이 부여될 때마다 해당 프로젝트 사이트 권한이 업데이트됩니다.

이 동기화는 프로젝트가 게시될 때마다 발생합니다. 동기화 편의를 위한 장단점은 성능입니다. 예를 들어 동기화해야 하는 사용자와 사이트가 많을수록 작업 속도가 느려집니다. 특히 프로젝트 사이트를 사용하여 여러 프로젝트를 대량 게시, 가져오기 또는 만들거나 프로젝트 사이트 사용 권한을 다시 동기화해야 하는 그룹 멤버 자격을 업데이트하는 경우 더욱 그렇습니다.

각 EPT에 대해 동기화 사용자 권한이 켜져 있는지 정의할 수 있습니다.

참고

프로젝트 사이트가 Project Web App 사이트가 있는 위치와 다른 사이트 모음에 만들어지는 경우(예: https://contoso.sharepoint.com/sites/pwa Project Web App 위치이고 EPT가 에서 https://contoso.sharepoint.com/sites/IT프로젝트 사이트를 만드는 경우) 사용자 권한 동기화가 지원되지 않습니다.

추천:

다음이 배포에 해당하는 경우 프로젝트 사이트 권한 동기화 옵션을 사용하지 않도록 설정하는 것이 좋습니다.

• 많은 수의 리소스가 있습니다(>1000)

• 프로젝트 사이트(>1000)가 필요한 많은 프로젝트가 있습니다.

• 대부분의 프로젝트 사이트에 대한 액세스 권한을 부여해야 하는 많은 수의 리소스가 있습니다.

• 프로젝트 사이트는 기본 사이트 모음 외부에서 만들어집니다(동기화를 사용하지 않도록 설정됨).

다음은 프로젝트 사이트 사용 권한을 관리하기 위해 고려해야 할 몇 가지 옵션입니다.

• 프로젝트 팀의 이직률이 낮은 경우 프로젝트 게시 및 프로젝트 세부 정보 페이지 성능을 개선하기 위해 프로젝트 사이트 권한 동기화를 해제하는 것이 좋습니다. 그런 다음 누군가가 프로젝트 팀에 참가하거나 떠날 때마다 프로젝트 사이트에 대한 권한을 수동으로 부여하거나 제거해야 합니다.

• PWA의 모든 사용자에게 액세스 권한을 부여해야 하고 기존 그룹 권한에 매핑되는 경우 부모 PWA 사이트에서 상속 하도록 프로젝트 사이트를 구성하는 것이 좋습니다.

• 사이트 액세스가 특정 역할과 일치하는 경우 해당 역할에 매핑되는 하나 이상의 그룹을 만들고(그룹 동기화를 사용하도록 설정한 경우 동일한 그룹을 사용할 수 있음) 해당 그룹에 프로젝트 사이트에 대한 액세스 권한을 부여합니다.

각 EPT에 대해 다음을 통해 사용자 허용 동기화를 켤 수 있습니다.

1. Project Web App 설정에서 엔터프라이즈 프로젝트 형식을 클릭합니다.

2. 설정을 변경해야 하는 EPT를 선택합니다.

3. EPT 설정 페이지의 동기화 섹션에서 사용자 권한 동기화를 선택합니다.

   

엔터프라이즈 프로젝트에 대한 SharePoint 작업 목록 동기화

SharePoint 작업 목록 동기화 는 프로젝트 게시 속도를 향상시키기 위해 기본적으로 꺼져 있습니다. 또한 프로젝트 세부 정보 페이지 간의 전환 속도를 높일 수 있습니다. 사용자가 프로젝트 사이트의 작업 목록 및 타임라인 시각화를 사용하는 경우 이 기능을 켜고 프로젝트 게시 성능에 미치는 영향이 적절한지 확인할 수 있습니다.

참고

프로젝트 사이트가 Project Web App 사이트가 있는 위치와 다른 사이트 모음에 만들어지는 경우(예: https://contoso.sharepoint.com/sites/pwa Project Web App 있는 위치이고 EPT가 에서 https://contoso.sharepoint.com/sites/IT프로젝트 사이트를 만드는 경우) SharePoint 작업 목록 동기화가 지원되지 않습니다.

권장 사항

SharePoint 작업 목록 동기화 옵션은 작은 프로젝트 계획에서 사용하기 위한 것이었습니다. 프로젝트에 많은 수의 태스크가 있는 경우 각 작업을 한 번에 하나씩 업데이트해야 하므로 게시 시 동기화하는 데 다소 시간이 소요됩니다. 예를 들어 500 작업 프로젝트 계획을 SharePoint 작업 목록과 동기화하는 데 몇 분 정도 걸립니다. 큐 작업이 별도의 상관 관계에 있고 프로젝트 계획의 저장 및 편집을 차단하지 않더라도 SharePoint 작업 목록 동기화 옵션을 사용하지 않는 것이 좋습니다. 250개 미만의 작업으로만 프로젝트를 동기화하는 것이 좋습니다.

이 옵션은 기본적으로 꺼져 있습니다. 사용자가 각 EPT에 대한 기능이 필요한 경우에만 SharePoint 작업 목록 동기화를 켭니다. 이 옵션을 구성하려면 다음을 수행합니다.

1. Project Web App 설정에서 엔터프라이즈 프로젝트 형식을 클릭합니다.

2. 설정을 변경해야 하는 EPT를 선택합니다.

3. EPT 설정 페이지의 동기화 섹션에서 SharePoint 작업 목록 동기화를 선택합니다.

   

Active Directory 리소스 풀 동기화

Active Directory 리소스 풀 동기화 자체는 특정 성능 문제가 없으며 몇 분 안에 수천 개의 리소스를 Project Web App 인스턴스로 가져올 수 있습니다. 그러나 시스템의 다른 부분에 대한 다운스트림 효과는 성능에 영향을 줄 수 있습니다. 감시하는 기본 프로세스는 이전에 언급한 리소스 권한 동기화입니다. Active Directory 그룹 멤버 자격에 큰 회전율이 있고 리소스 풀을 자주 동기화해야 하는 경우 관련 권한 동기화 작업에 대한 잠재적인 다운스트림 영향을 모니터링합니다.

추천:

Active Directory 동기화를 실제로 시스템을 사용해야 하는 리소스 그룹으로 제한하고 대규모 그룹을 동기화한 후 잠재적인 권한 문제를 모니터링합니다. (Active Directory Enterprise 리소스 풀 동기화를 구성하려면 Project Web App 설정에서 Active Directory 리소스 풀 동기화를 클릭합니다.

PWA 페이지 및 뷰 사용자 지정

페이지 사용자 지정

SharePoint 플랫폼은 모듈식 웹 파트 인프라와 사용자 지정 페이지에 대한 지원을 통해 뛰어난 사용자 지정 기능을 제공합니다. 로고, 사용자 지정 웹 파트 및 새 테마를 추가할 때 서버 근접성, 짧은 대기 시간 및 높은 대역폭 네트워크의 이점으로 인해 온-프레미스 인프라의 성능에 큰 영향을 미치지 않을 수 있습니다. 그러나 온라인 서비스에서는 이야기가 다릅니다.

파일 크기가 큰 로고나 그래픽을 업로드하면 온-프레미스 배포에서 페이지 속도가 약간 느려질 수 있지만 온라인에서는 페이지 로드의 성능이 상당히 저하됩니다.

페이지에 여러 웹 파트를 추가할 때도 동일한 원칙이 적용됩니다. 여러 웹 파트가 있는 사용자 지정 페이지가 있는 것은 유혹적일 수 있지만 사용자가 실제로 데이터를 나란히 볼 필요가 없다면 모든 페이지를 한 곳에 배치하는 것보다 별도의 특수 페이지를 갖는 것이 좋습니다. 사용자가 페이지에 있는 한 웹 파트의 콘텐츠만 필요한 경우 다른 모든 웹 파트에 대한 데이터를 로드하고 표시하기 위해 페이지가 로드될 때까지 더 오래 기다려야 합니다.

추천:

페이지를 사용자 지정하는 경우 Project Online 사이트를 일반 인터넷 웹 사이트로 처리하고 가능한 한 간단한 페이지를 만듭니다.

뷰 사용자 지정

여기서도 단순성은 페이지 로드 성능을 향상시키는 데 큰 길을 갑니다. 조직은 Project Center, Resource Center, 작업 및 작업표를 비롯한 여러 Project Web App 페이지를 사용하여 사용자 지정 보기를 만들 수 있습니다.

콘텐츠가 더 많이 표시될수록 페이지 렌더링 속도가 느려집니다. 사용자에게 몇 가지 "올인원" 보기가 아닌 더 많은 수의 단순하고 대상으로 지정된 보기를 제공하는 경우 각 페이지 로드 시간을 몇 초 단축할 수 있습니다.

아래 예제에서 두 번째 보기는 첫 번째 보기보다 로드하는 데 평균 2~3초가 걸립니다.

추천:

보기를 구성할 때 대부분의 경우 불필요한 데이터를 로드하는 복잡한 올인원 보기가 아닌 빠른 탐색을 위해 사용자에게 간단한 특수 보기를 제공합니다.

사용자 보기 설정

프로젝트 센터: 롤업으로 그룹화

사용자는 다른 필드별로 데이터를 그룹화하는 것을 포함하여 보기를 렌더링하는 다양한 방법을 구성할 수 있습니다. 그룹화 기준 사용 시 지원되는 집계 필드(예: 비용 합계 또는 사용자 지정 필드)에 대한 데이터를 롤업할 수 있습니다. 이러한 집계 값을 계산하면 서비스가 합계를 표시하기 위해 모든 값을 로드하도록 요청합니다.

추천:

사용자가 롤업된 값을 볼 필요가 없는 한 리본에서 롤업 옵션을 사용하지 않도록 설정합니다.

프로젝트 센터: Gantt 차트

Gantt 차트 보기의 차트 부분에는 각 프로젝트가 요약 Gantt 막대로 표시됩니다.

추천:

사용자가 Gantt를 볼 필요가 없는 한 리본에서 Gantt 차트 옵션을 사용하지 않도록 설정합니다.

사용자 지정 프로젝트 세부 정보 페이지 및 워크플로

페이지 디자인에 대해 위에서 제공된 권장 사항 외에도 PDP(프로젝트 세부 정보 페이지)는 전체 프로젝트의 다시 계산을 트리거하고 워크플로 작업을 시작할 수 있으며, 사용자 지정에 따라 성능 측면에서 비용이 많이 드는 작업이 될 수 있다는 점에서 특히 중요합니다.

Project Online 및 Project Server에는 프로젝트 정보에 대한 두 가지 주요 업데이트 프로세스가 있습니다.

• 예약 다시 계산이 필요한 업데이트(아래 목록 참조)

• 프로젝트 이름, 설명 및 소유자와 같은 예약되지 않은 관련 필드입니다.

두 업데이트 프로세스를 동시에 트리거하지 않도록 동일한 PDP에서 두 유형의 데이터를 업데이트하지 않는 것이 좋습니다.

다음은 일정 다시 계산이 필요한 가장 일반적인 작업 목록입니다.

• 프로젝트 일정 변경 내용

• 다음 날짜 필드의 변경 내용:

  • 시작 날짜

  • 완료 날짜

  • 상태 날짜

  • 현재 날짜

• 프로젝트 사용자 지정 필드의 변경 내용

• 프로젝트에 결과물에 대한 종속성이 있는 경우

PDP 성능을 개선하는 두 번째 방법은 각 PDP에 표시되는 웹 파트 및 사용자 지정 필드 수를 줄이는 것입니다. 비즈니스 프로세스에서 동일한 필드 집합을 자주 업데이트해야 하는 경우 이러한 필드만 있는 전용 PDP를 만들어 부하를 개선하고 시간을 절약합니다. 항상 모든 사용자 지정 필드를 표시하면 불필요한 오버헤드가 많이 발생합니다.

추천:

경량 특수 PDP를 만들고 일정 관련 업데이트와 예정되지 않은 업데이트가 혼합되지 않도록 합니다.

새 REST API를 사용하여 워크플로에서 대량 사용자 지정 필드 업데이트

워크플로에서 프로젝트 사용자 지정 필드 값을 한 번에 하나씩 업데이트하려면 프로젝트 필드 설정 작업을 사용하여 별도의 서버 요청이 필요합니다. 이로 인해 대기 시간이 긴 낮은 대역폭 네트워크에서 동시에 많은 사용자 지정 필드를 업데이트할 때 성능이 저하됩니다.

이 문제를 해결하기 위해 사용자 지정 필드를 대량으로 업데이트하는 CSOM 메서드가 있습니다. 이 메서드를 사용하려면 업데이트하려는 모든 사용자 지정 필드의 이름과 값이 포함된 사전을 전달해야 합니다.

요청 시 프로젝트 사이트를 프로비전하기 위한 API

각 프로젝트에는 팀 구성원이 공동 작업하고, 문서를 공유하고, 문제를 제기할 수 있는 고유한 전용 SharePoint 사이트가 있을 수 있습니다. 이러한 사이트는 Project Pro 또는 관리자를 통해 프로젝트 관리자가 처음 게시할 때 자동으로 만들거나 수동으로 만들거나 Project Web App 설정을 통해 만들거나 사용하지 않도록 설정할 수 있습니다.

CreateProjectSite('') 메서드를 사용하여 프로젝트 사이트를 만들 시기를 결정할 수 있습니다. 이는 프로젝트 제안이 처음 게시가 아닌 미리 정의된 워크플로의 특정 단계에 도달한 후에만 사이트를 만들려는 조직에 특히 유용합니다. 이렇게 하면 프로젝트 사이트 만들기를 연기하여 프로젝트 만들기의 성능이 크게 향상됩니다.

이벤트 처리

추가 기능은 Project Online 발생하는 이벤트에 응답할 수 있습니다. 예를 들어 추가 기능은 프로젝트를 만든 후 몇 가지 추가 작업을 수행할 수 있습니다. 사용자는 이러한 추가 기능이 이벤트 처리를 완료할 때까지 기다려야 Project Online 작업을 계속할 수 있습니다.

추천:

Project Online 사용자가 기다려야 하는 시간을 최소화하기 위해 특정 이벤트를 비동기적으로 처리하도록 구성해야 합니다. 이렇게 하려면 코드가 After 이벤트를 비동기적으로 처리할 수 있는지 확인하기 위해 사용하는 추가 기능의 개발자에게 문의하세요. 이 문서로 이동하여 이러한 이벤트를 처리하기 위해 따를 수 있는 사례에 대해 자세히 알아볼 수 있습니다.

개발자가 추가 기능을 변경할 준비가 되었는지 확인한 경우 PWA 설정 페이지에서 비동기 후 이벤트 처리 설정 켜기를 사용하도록 설정해야 합니다.

1. PWA 설정 페이지의 운영 정책 섹션에서 추가 서버 설정을 선택합니다.

2. After 이벤트에 대한 비동기 이벤트 처리 섹션에서 이벤트처리 후 비동기 설정이 선택되어 있는지 확인합니다.

   

3. 저장을 선택합니다.

   그런 다음 인스턴스를 테스트하여 모든 것이 올바르게 작동하는지 확인해야 합니다.

   참고

   이 설정은 사이트 모음 관리자만 보고 변경할 수 있습니다.

OData 및 보고

ProjectData OData 서비스

Project Online 서비스에 저장된 데이터에 대한 보고/시각화를 빌드하는 방법을 제공하는 OData 보고 서비스가 있습니다. ProjectData OData Reporting Service API는 여기에 정의되어 있습니다.

ProjectData OData 보고 서비스에 대한 호출은 SharePoint Online에 의해 관리됩니다. SharePoint Online에서 제한 또는 차단 방지 문서를 검토하여 호출이 제한될 가능성이 낮고 다시 시도 및 지수 백오프 권장 사항을 올바르게 구현하는지 확인하세요.

또한 이 문서에 설명된 권장 사항에 따라 데이터를 검색하는 데 필요한 호출 수, 길이 및 빈도를 줄일 수 있습니다. 제한이 자주 발생하는 경우 여러 부서가 동일한 데이터를 쿼리하거나 이 문서에 설명된 모범 사례를 따르지 않고 모든 사람에게 영향을 미칠 수 있으므로 조직 전체에서 확인합니다.

시간 단계별 보고

Project Online 시간별 보고 데이터에 필요한 세분성 수준을 선택할 수 있습니다. 수준의 옵션 및 영향은 Project Online 시간별 보고 데이터의 롤업 구성에 자세히 설명되어 있습니다. 시나리오에 가장 적은 양의 데이터를 생성하는 수준을 선택하면 OData Reporting Service 엔드포인트에서 데이터를 더 빠르게 볼 수 있으며 다운로드하는 데 걸리는 시간이 줄어듭니다.

성능 순서의 옵션 목록입니다(생성된 데이터의 양과 상관 관계가 가장 낮은 것부터 가장 적은 성능까지):

• 없음

• 회계 기간

• 매월

• 매주

• 매일

회계 기간은 보고 데이터가 정의된 회계 기간 동안만 유지되는 반면 월별은 모든 프로젝트에서 전체 기간 동안 데이터를 보유한다는 측면에서 월별보다 큰 이점이 있습니다.

Project OData 서비스를 사용하여 Project Online 인스턴스에서 보고를 위해 정보를 추출할 수 있습니다.

추천:

비즈니스 요구 사항과 일치하는 최소 시간 제한 데이터를 저장합니다. 게시가 완료되기를 기다리는 워크플로가 있는 경우 매일을 사용하지 마세요. 워크플로가 대기하는 데 필요한 데이터를 생성하는 데 매일 상당한 시간이 걸릴 수 있습니다.

서비스 쿼리

ProjectData OData 서비스의 한 쿼리에서 반환할 수 있는 엔터티 수에는 제한이 있습니다. 따라서 대량의 데이터를 쿼리하려면 여러 웹 요청을 서비스로 전송하여 각 요청에 대한 네트워크 오버헤드 및 대기 시간을 추가해야 합니다.

추천:

전체 "모든 항목 새로 고침" 데이터 로드를 수행하지 마세요. 이러한 새로 고침은 특히 PWA에서 사용자 작업의 전반적인 성능 저하 또는 제한으로 이어지는 사용량이 많은 시간에 PWA 사이트의 성능에 영향을 미칠 수 있습니다.

몇 시간 후에 Odata 새로 고침 작업을 수행합니다. 실시간 또는 실제 보고서에 가깝게 유지 관리하려면 PWA 사이트의 사용자 환경에 대한 성능 장단도 고려해야 합니다. "모든 항목 새로 고침" 요구 사항이 있는 경우 "SQL Server Integration Services(SSIS) – 대용량 데이터 세트에 권장됨" 섹션을 검토하세요.

프로젝트, 할당 또는 태스크와 같이 많은 수의 엔터티를 포함하는 Project Web App 인스턴스의 경우 다음 방법 중 하나 이상에서 반환되는 데이터를 제한해야 합니다. 반환된 데이터를 제한하지 않으면 쿼리가 기본 제한을 초과하여 서버 성능에 영향을 줄 수 있습니다.

• 항상 $filter URL 옵션을 사용하고 $select 사용하여 데이터를 제한합니다. 예를 들어 다음 쿼리는 프로젝트 시작 날짜를 기준으로 필터링하고 프로젝트 이름 순서대로 4개의 필드만 반환합니다.

  http://ServerName/ProjectServerName/_api/ProjectData/Projects?$filter=ProjectStartDate gt datetime'2012-01-01T00:00:00'&$orderby=ProjectName&$select=ProjectName,ProjectStartDate,ProjectFinishDate,ProjectCost
  

• 다중 값 조회인 사용자 지정 필드를 사용하지 마세요. 다중 값 조회인 사용자 지정 필드 값을 처리하려면 추가 계산이 필요합니다. 이러한 필드는 보다 일반적인 고객 시나리오를 위해 구현된 몇 가지 최적화를 활용할 수 없습니다. 다중 값 사용자 지정 필드가 이미 구성된 경우 필터링된 Odata 쿼리에 이러한 필드가 지정되지 않도록 하여 조회 속도 및 안정성을 향상시킵니다.

• 키 또는 연결을 기준으로 엔터티 쿼리 엔터티를 쿼리할 때 의 https://yourdomain.sharepoint.com/sites/PWA/_api/ProjectData/$metadata메타데이터 문서를 참조하세요. 가능한 경우 다음 방법 중 하나로 엔터티를 쿼리합니다.

• 키

  참고

  둘 이상의 키가 있는 경우 첫 번째 키를 사용하면 두 번째 키만 사용하는 것보다 더 나은 성능을 발휘합니다.

• 연결

  예를 들어 AssignmentId 및 ProjectId를 통해 할당 엔터티를 쿼리할 수 있습니다.

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter=AssignmentId eq guid'719d849a-79b4-e911-b073-00155d9c3d12' and ProjectId eq guid'b5b02399-79b4-e911-b073-00155d9c3d12'
  
  or
  
  https://ServerName/ProjectServerName/_api/ProjectData/Assignments(AssignmentId=guid'719d849a-79b4-e911-b073-00155d9c3d12',ProjectId=guid'b5b02399-79b4-e911-b073-00155d9c3d12') 
  

  AssignmentId를 통해:

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter=AssignmentId eq guid'719d849a-79b4-e911-b073-00155d9c3d12'
  

  ProjectId를 통해 다음을 수행합니다.

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter= ProjectId eq guid'b5b02399-79b4-e911-b073-00155d9c3d12'
  

  Project를 통한 연결을 통해 다음을 수행합니다.

  https://ServerName/ProjectServerName/_api/ProjectData/Projects(guid'263fc8d7-427c-e111-92fc-00155d3ba208')/Assignments
  

• 루프에서 $top 연산자와 $skip 연산자를 사용하여 데이터를 한 번에 한 페이지씩 반환하려면 여러 쿼리를 수행합니다. 예를 들어 다음 쿼리는 문제에 할당된 리소스 순서대로 모든 프로젝트에 대해 문제 11~20을 가져옵니다.

  https://ServerName/ProjectServerName/_api/ProjectData/Issues?$skip=10&$top=10&$orderby=AssignedToResource
  

• 할당 엔터티를 쿼리할 때 프로젝트/작업/리소스 이름을 검색하지 않습니다. 서비스는 추가 처리를 수행하여 해당 이름을 검색합니다. 데이터가 이미 다른 쿼리에서 검색된 경우 할당을 쿼리할 때 $select 필터에 포함하지 마세요.

추천:

• 서버 쪽 필터링을 사용하여 필요한 열만 검색하여 런타임에 쿼리하는 데이터의 양을 제한합니다. 이러한 영향은 사용자 지정 필드에서 가장 두드러집니다. 필요한 경우에만 사용자 지정 필드에 를 추가합니다.

• 엔터티 키를 필터링하고 있는지 확인합니다. 엔터티 키는 인덱싱되며 훨씬 더 성능이 좋은 데이터 검색 환경을 제공합니다. PWA 인스턴스에서 서비스 메타데이터 문서를 검토하여 각 엔터티에 대한 키를 찾을 수 있습니다. $metadatahttps://Contoso.sharepoint.com/sites/PWA/_api/ProjectData/

데이터 검색 및 보고서 작성

PowerBI

데이터 양이 작은 경우 Power BI는 Project OData 서비스에서 정기적으로 데이터를 읽고 다양한 Dynamics 보고서를 제공할 수 있습니다. 샘플 콘텐츠 팩은 여기에서 찾을 수 있습니다.

Project Online 데이터의 양이 크면 여기에 설명된 PowerBI 데이터 크기 제한을 충족하는 한 데이터의 하위 집합을 가져올 수 있습니다. 또 다른 옵션은 이동 창에서 보고서를 만드는 것입니다. 즉, 지난 30일 동안 활성화된 프로젝트를 필터링하거나 다음 6개월 동안 리소스 용량을 보는 것입니다. PowerBI가 서비스 쪽 필터링 최적화를 활용하지 못할 수 있으므로 모범 사례는 $filter/$select 섹션을 검토하세요.

Excel OData

Excel을 사용하여 데이터를 다운로드하고 사용자 지정 시각화/보고서를 작성할 수 있습니다. Project Online 데이터의 양이 크면 데이터의 하위 집합이 이동 기간(예: 지난 30일 동안 활성화된 프로젝트 필터링 또는 향후 6개월 동안 리소스 용량 보기)을 사용할 수 있습니다. Excel이 서비스 쪽 필터링 최적화를 활용하지 못할 수 있으므로 모범 사례는 $filter/$select 섹션을 검토하세요.

SQL Server Integration Services(SSIS)

SSIS를 사용하여 Project Online 보고 데이터를 Project OData 서비스에서 로컬 SQL Server 데이터베이스 또는 Microsoft Azure로 다운로드할 수 있습니다. 다운로드되면 모든 보고서/시각화를 작성할 수 있습니다. 로컬 데이터를 Project Online 동기화하려면 추가 프로세스가 필요합니다.

SSIS를 사용하는 경우 Project Online 최적화된 다음 패턴을 사용합니다. 패턴은 로컬 데이터를 검색하고 동기화된 상태로 유지하는 데 걸리는 시간을 줄입니다. 또한 비즈니스 요구 사항을 수행하는 데 필요한 필드만 다운로드합니다. 쿼리되는 필드가 적을수록 데이터를 더 빠르게 검색할 수 있습니다.

전체 동기화

관심 있는 보고 데이터의 현재 스냅샷을 검색합니다. Project 및 관련 엔터티를 효율적으로 검색하려면 다음 방법을 사용합니다.

예를 들어 프로젝트 엔터티를 사용하세요.

1. 추가 필터를 포함하여 Project 엔터티에서 ProjectId를 쿼리합니다. 예를 들어 특정 시작 또는 완료 날짜가 있는 프로젝트를 필터링합니다.

2. 이전에 검색한 단일 ProjectId에서 필터링하여 다운로드해야 하는 필드를 지정하는 Project 엔터티를 쿼리합니다. 아래 델타 동기화 패턴에 사용되는 ProjectModifiedDate를 포함합니다.

3. 각 ProjectId에 대해 2단계를 반복합니다. 또한 각 ProjectId에 대해 관련 엔터티에 대한 데이터를 다운로드합니다.

예를 들어 작업 엔터티를 사용합니다.

1. 이전 단계의 ProjectId 프로젝트뿐만 아니라 추가 필드에 대한 작업 엔터티 필터링의 TaskId를 쿼리합니다.

2. 다운로드해야 하는 필드를 지정하고 이전에 검색한 단일 TaskId에서 필터링하는 작업 엔터티를 쿼리합니다. 아래 델타 동기화 패턴에 사용되는 TaskModifiedDate를 포함합니다.

3. 각 TaskId에 대해 반복합니다.

   마찬가지로, 각 관련 엔터티(예: 할당, TaskTimephasedData)에 대해 동일한 방법을 사용합니다.

앞의 단계는 작업표 정보를 검색할 때와 같은 다른 엔터티 그룹에 적용됩니다.

• 작업표: 필터 조건에 따라 TimesheetId 및 ModifiedDate를 검색한 다음, 작업표 레코드를 기록한 다음 TimeSheetId에서 TimeSheetLines 필터링을 계속하여 다른 관련 엔터티로 계속 진행하여 주 키 ID(TimesheetUID) 및 수정 날짜 필드를 기준으로 파일링하고 있는지 확인합니다.

리소스 엔터티 정보를 검색하는 경우:

• ResourceId 및 ResourceModifiedDate, 리소스 레코드, ResourceTimephasedData 등을 검색합니다. 각 기본 키 ID 및 수정 날짜 필드를 포함합니다.

델타 동기화

보고 데이터의 로컬 복사본을 최신 상태로 유지하려면 주기적으로 확인합니다. 각 자격 그룹(예: 작업표, 리소스...)에 대해 필요에 따라 아래 단계를 반복합니다.

1. $filter 조건을 사용하여 Project 엔드포인트의 모든 ProjectId 및 수정 날짜를 쿼리합니다.

2. ProjectId가 더 이상 존재하지 않는 로컬 프로젝트 및 관련 레코드(작업, 할당 등)를 삭제합니다.

3. 프로젝트 레코드에 대해 서비스 수정 날짜와 로컬 수정 날짜가 다른 경우 한 번에 단일 ProjectId에서 필터링하는 모든 필수 필드에 대해 Project 엔드포인트를 쿼리합니다. 또한 각 ProjectId에 대해 관련 엔터티에 대한 데이터를 다운로드합니다.

예를 들어 작업 엔터티를 사용합니다.

1. 데이터가 변경된 이전 단계의 프로젝트 ProjectId뿐만 아니라 추가 필드에 대한 작업 엔터티 필터링의 TaskId 및 TaskModifiedDate에 대한 쿼리, 즉 프로젝트 서비스 수정 날짜가 로컬 수정 날짜와 일치하지 않습니다.

2. 더 이상 존재하지 않는 TaskId에 대한 로컬 및 관련 레코드를 삭제합니다.

3. 서비스 수정 날짜와 로컬 수정 날짜가 다른 경우 TaskId 및 엔터티 기본 키를 전달하는 각 엔터티 엔드포인트를 쿼리하고 로컬 버전을 업데이트합니다.

각 관련 엔터티(예: Assignment, TaskTimephasedData)에 대해 반복합니다.

Project Web App 할당량

기본적으로 Project Web App 사이트는 25GB 제한과 함께 제공되며 Project Web App 사용하도록 설정된 SharePoint 사이트 모음에 저장된 모든 데이터에 대한 제한과는 별개입니다. 보고 세분성 옵션을 사용하여 데이터 볼륨을 줄이면 할당량 내에서 유지하는 데 도움이 될 수 있습니다.

참고

PWA 할당량을 최대 100GB로 늘릴 수 있습니다(증분). 할당량 한도에 도달하면 새 PWA 사이트가 필요합니다. 50GB를 초과하면 PWA 사이트에서 더 이상 일별 시간대별 보고 세분성 옵션을 사용하지 않아도 됩니다. PWA 사이트 할당량 증가를 논의하려면 Microsoft에 문의하세요.

결론

Project Online 인터넷에서 실행되는 클라우드 서비스와 마찬가지로 온-프레미스 배포에 비해 최상의 성능을 제공하기 위해 특정 튜닝이 필요합니다.

성능 향상을 위해 시스템을 지속적으로 개선하고 있지만, 최종 사용자에게 좋은 환경을 제공하기 위해 그 동안 수행할 수 있는 몇 가지 단계가 있습니다.

요약 권장 사항:

• 가능한 경우 SharePoint 사용 권한 모드를 사용합니다.

• 실제로 사용할 기능만 켭니다.

• 페이지 로드 시간을 단축하기 위해 페이지 및 사용자 지정을 가능한 한 간단하고 간단하게 유지합니다.

• 더 많은 보고 유연성을 위해 서버 쪽 필터링을 사용하거나 Odata 피드 데이터를 SQL Server 데이터베이스로 내보냅니다.

• 보고 요구 사항을 충족하는 최소한의 데이터를 사용하는 보고 세분성 옵션을 선택합니다.

관련 주제

Project Online: 소프트웨어 경계 및 제한