Microsoft Office Project Server 2007 큐 시스템
업데이트 날짜: 2009년 5월
마지막으로 수정된 항목: 2015-02-27
이 문서의 내용
개요
큐 프로세스
큐 아키텍처
프로젝트 및 작업표 큐
큐 배포
큐 그룹화
큐 상태
큐 관리
큐 관리 작업
이 문서에서는 Microsoft Office Project Server 2007 큐 시스템에 대해 설명합니다. 큐 시스템은 Project Server 2007 버전에 새로 추가된 주요 기능입니다. 이 문서에서는 큐 시스템에 대한 개요, 큐 프로세스 및 아키텍처, 큐 작업이 그룹화되는 방식, 큐 작업의 상태 등을 다루고 Microsoft Office Project Web Access 사용자 인터페이스를 통해 큐를 관리하는 방법을 설명합니다.
개요
큐는 서비스 요청 수가 최적의 서비스 처리 용량보다 많아질 경우 필요한 대기 줄입니다. Enterprise 프로젝트 관리 시스템에서는 이런 경우에 해당하는 여러 가지 사례를 찾아볼 수 있습니다. 예를 들면 다음과 같습니다.
금요일에 한 주의 업무가 끝나면 소규모 기업의 직원 500명이 거의 모두 작업표를 제출합니다.
팀 상황 회의를 하기 몇 시간 전에 거의 모든 프로젝트 관리자가 프로젝트를 게시합니다.
Office Project Server 2007 큐 시스템의 목적은 이처럼 갑작스러운 요청의 변화를 무리 없이 안정적으로 처리하는 것입니다. Office Project Server 2007 큐 시스템은 모든 사용자의 입력 내용을 받아 요청 항목을 Microsoft SQL Server에 기록한 다음 데이터를 선착순 비동기식으로 처리합니다. 큐가 있으면 갑자기 요청이 늘어나도 Office Project Server 2007 EPM 솔루션의 작동이 중지되지 않습니다.
Office Project Server 2007 시스템에서 중요한 작업은 거의 모두 Office Project Server 2007 큐 시스템을 통해 처리됩니다. 다음과 같은 작업이 큐 시스템을 통해 처리됩니다.
프로젝트 저장
프로젝트 게시
작업표 저장
작업표 제출
프로젝트 백업/복구
보고서 데이터 서비스 작업
큐브 작성 서비스 작업
서버 쪽 일정(및 노드 일관성 처리)
Project Server 큐 시스템을 사용하면 다음과 같은 이점이 있습니다.
안정성
데이터 무결성: 큐에는 작업을 저장할 수 있도록 잘 정의된 프로토콜이 있습니다. 작업이 반만 저장된 경우 해당 작업은 처리되지 않습니다. 또한 모든 작업이 파일 시스템이 아니라 SQL Server에 저장되어 SQL Server 트랜잭션을 활용합니다.
순차적 전달: Project Professional의 사용자가 저장을 클릭한 다음 게시를 클릭하면 Project 큐 시스템에서 저장 작업을 먼저 처리하고 이어서 게시 작업을 처리합니다.
내결함성: 큐에 있는 실패한 작업을 다시 시도할 수 있습니다. 또한 큐 NT 서비스의 인스턴스가 둘 이상 실행되는 경우 그 중 하나가 응답을 중지하면 다른 하나가 자동으로 추가 부하를 처리합니다. 이러한 프로세스를 *투명 장애 조치(transparent failover)*라고 합니다.
확장성
다중 스레딩: Office Project Server 2007 큐 시스템은 동시에 여러 작업을 처리할 수 있습니다. 예를 들어 프로젝트 1 저장, 프로젝트 2 게시 및 큐브 작성 작업을 동시에 처리할 수 있습니다.
중간 계층 서버를 더 추가하여 부하를 보다 원활하게 처리할 수 있습니다. 각 중간 계층 서버에는 Project 큐 서비스가 있으며 자동으로 부하가 분산됩니다.
큐의 작업 수는 SQL Server의 배율 제한으로만 한정됩니다.
관리 효율성
큐 프로세스
다음 그림은 큐 프로세스를 보여 줍니다.
.gif "Project Server 2007 큐 프로세스")
사용자가 클라이언트 응용 프로그램에서 서버 요청(예: Project Professional에서 프로젝트 게시)을 만들고 작업 ID(요청을 추적하는 고유한 식별자)를 요청의 일부로 전달합니다.
Project 웹 서비스가 요청을 받아 큐로 보냅니다.
승인 표시로 사용자에게 작업 ID가 발급됩니다.
사용자가 발급된 작업 ID를 통해 요청의 상태를 확인하기 위해 쿼리합니다.
Office Project Server 2007 큐 시스템에서 사용자에게 요청의 상태를 반환합니다.
큐 아키텍처
Project Server 큐 시스템 논리 아키텍처는 다음 네 가지 모듈로 구성됩니다.
작업 저장
작업 폴링
작업 처리
작업 상태 확인 및 관리
Project Server 큐 서비스에 작업 추가 또는 처리, 상태 검색 등의 요청이 들어오면 이러한 모듈이 한꺼번에 작동하여 필요한 작업을 수행합니다. 이 섹션에서는 이러한 프로세스에 대해 자세히 설명합니다.
큐 모듈
구축의 한 과정으로 모든 Project Server 응용 프로그램 서버 컴퓨터에 큐 NT 서비스가 설치됩니다. 팜에 정의된 SSP(공유 서비스 공급자)마다 하나의 "큐 작업자 프로세스"가 시작됩니다. 큐 작업자 프로세스는 해당 SSP와 연결된 Project Web Access(PWA)의 모든 인스턴스에 서비스를 제공하고 "SSP 관리자" ID로 실행됩니다. 이 섹션의 나머지 부분을 살펴볼 때 이 배포 모델을 기억하십시오. 자세한 내용은 이문서 뒷부분의 큐 배포를 참조하십시오.
.gif "Project Server 2007 큐 NT 서비스")
Project Server 큐 시스템은 다음 네 가지 모듈로 구성됩니다.
작업 저장소: 큐 작업은 Project Server의 임시 데이터베이스와 게시된 데이터베이스에 저장됩니다. 이런 방식으로 작업이 일반적인 Project Server 데이터베이스 백업 및 복구 루틴의 일부로 백업되고 복원됩니다.
.gif "작업 저장소")
작업 폴링: 작업 폴링 스레드에서 새 작업을 확인하기 위해 일정한 간격으로 작업 저장소를 폴링합니다. 폴링 간격은 관리자가 Project Web Access 큐 관리 페이지에서 구성합니다.
.jpg "작업 폴링")
큐 작업자 프로세스는 해당 프로세스가 서비스를 제공하는 PWA의 각 인스턴스에 대해 작업 폴링 스레드를 시작합니다. 작업 폴링 스레드는 "큐 작업자 프로세스" 프로세스 내에서 "큐 작업자 프로세스" ID로 실행됩니다.
작업 폴링 스레드의 두 가지 주요 속성은 다음과 같습니다.
속성 설명 유형
지정된 작업 폴링 스레드는 "프로젝트 작업 폴링 스레드"(프로젝트 관련 작업 검색) 또는 "작업표 작업 폴링 스레드"(작업표 관련 작업 검색)일 수 있습니다.
Project Web Access 인스턴스
모든 작업 폴링 스레드는 Project Web Access의 특정 인스턴스에서 시작된 작업을 검색합니다.
작업 처리: 작업 폴링 스레드는 검색한 각 작업에 대해 작업 처리 스레드를 하나씩 생성합니다. 관리자는 최대 작업 처리 스레드 수를 구성할 수 있습니다. 작업 처리 스레드는 "큐 NT 서비스" 프로세스 내에 있으며 "큐 NT 서비스" ID로 실행됩니다.
.gif "Project Server 2007 - 큐 작업 처리")
작업 상태 확인 및 관리: 최종 사용자에게 표시되는 Project Server 큐의 모듈입니다.
.gif "작업 상태 확인 및 관리")
Project Web Access 큐 관리 페이지: 관리자는 이 페이지를 사용하여 큐의 모든 작업 상태를 봅니다. 실패한 작업을 취소하거나 다시 시도할 수도 있습니다. 이 기능은 PWA의 일부이므로 특별한 도구를 다운로드할 필요가 없습니다.
Project Web Access 큐 설정 페이지: 관리자는 폴링 간격 및 최대 작업 처리 스레드 수 같은 큐의 설정을 보거나 변경할 수 있습니다. 이 기능은 PWA의 일부이므로 특별한 도구를 다운로드할 필요가 없습니다.
Project Web Access 내 대기 작업 페이지: 모든 사용자는 이 인터페이스를 사용하여 작업의 상태를 확인할 수 있습니다. 이 기능은 PWA의 일부이므로 특별한 도구를 다운로드할 필요가 없습니다.
큐 상태 PSI: 소프트웨어 개발자는 이러한 API를 사용하여 모든 큐 작업의 상태를 확인할 수 있습니다. 검색 범위를 좁힐 수 있는 강력한 몇 가지 필터도 있습니다.
모든 모듈이 함께 작동되는 방식
시스템에서 작업 추가, 작업 처리, 작업 상태 검색 등의 요청을 처리해야 할 경우 Project Server 큐 시스템 모듈은 상호 작용하여 모두 한꺼번에 작동해야 합니다.
작업 추가
큐에 작업을 추가할 수 있는 방법에는 여러 가지가 있습니다. 예를 들어 프로젝트 관리자가 Project Professional에서 프로젝트를 저장할 수도 있고 팀 구성원이 작업표를 제출할 수도 있으며 타사 응용 프로그램에서 프로젝트를 게시할 수도 있습니다. 이러한 각 작업은 PSI(Project Server 인터페이스)의 요소를 호출하고 그 결과로 적절한 작업이 큐에 추가됩니다.
.gif "작업 추가--아키텍처")
작업 처리
작업 처리는 다양한 단계에서 서로 다른 모듈 간의 상호 작용을 통해 발생합니다.
큐 작업자 프로세스 시작: 큐 NT 서비스가 시작되면 이 서비스는 팜에 정의된 공유 서비스 공급자별로 큐 작업자 프로세스를 하나씩 시작합니다. Project 큐 시스템이 작동하려면 큐 NT 서비스가 항상 실행되고 있어야 합니다.
작업 폴링 스레드 시작: 큐 작업자 프로세스가 시작되면 이 프로세스에서 Project Web Access의 인스턴스와 관련된 작업 폴링 스레드를 시작합니다.
새 작업 선택: 폴링 스레드가 프로젝트 데이터베이스에서 새 작업을 찾습니다.
작업 처리 스레드 만들기: 새 작업이 있으면 작업 처리 스레드가 만들어집니다.
상태 쓰기: 작업 처리 스레드가 완료되면 작업 상태(성공 또는 실패)가 다시 데이터베이스에 기록됩니다.
.gif "Project Server 2007 작업 프로세스 큐")
상태 검색
작업 상태는 여러 가지 방법으로 확인할 수 있습니다. 관리자는 Project Web Access 큐 관리 페이지를 사용할 수 있고 팀 구성원은 내 대기 작업 페이지를 사용할 수 있으며 소프트웨어 개발자의 경우 큐 PSI 메서드를 사용하여 프로그래밍 방식으로 상태를 확인할 수 있습니다. PSI 메서드에 대한 자세한 내용은 MSDN Library Online(https://msdn.microsoft.com/ko-kr/library/bb187390.aspx)의 Project 2007 SDK 설명서 (영문)를 참조하십시오.
.gif "Project Server 2007 작업 상태 확인")
프로젝트 및 작업표 큐
Office Project Server 2007 큐 시스템은 다음 두 가지 큐로 구성됩니다.
프로젝트 큐 다른 유형의 메시지도 이 큐에 보낼 수 있지만 주로 저장, 게시, 보고, 큐브 작성 등 프로젝트 관련 메시지에 사용됩니다. 이 큐의 테이블 및 저장 프로시저는 Office Project Server 2007의 임시 데이터베이스에 저장됩니다.
작업표 큐 다른 유형의 메시지도 이 큐에 보낼 수 있지만 주로 작업표 저장, 작업표 제출 등 작업표 관련 메시지에 사용됩니다. 이 큐의 테이블 및 저장 프로시저는 Office Project Server 2007의 게시된 데이터베이스에 저장됩니다.
이 두 가지 큐는 작업이 서로 다른 데이터베이스에 있다는 점만 제외하고 같은 방식으로 디자인되었습니다. 두 가지 유형의 큐가 있으면 다음과 같은 장점이 있습니다.
성능: 코어 데이터와 동일한 데이터베이스에 큐 작업 데이터를 저장하면 큐가 작업 처리 중에 비용 부담이 큰 데이터베이스 간 호출을 만들지 않아도 됩니다. 예를 들어 작업표 제출 작업이 발생하면 사용자가 입력한 데이터(예: 작업한 시간)가 제출된 큐 작업의 일부로 패키징되어 SQL Server 작업 저장소로 전송됩니다. 또한 작업표에 대한 기존 정보(기간, 이름 등)가 이미 있고 "게시된" 데이터베이스에서 이 정보를 사용할 수 있습니다. 작업표 제출 작업을 처리하려면 두 데이터 집합이 모두 필요하며, 두 데이터 집합이 같은 데이터베이스에 있으면 성능이 향상됩니다. 이러한 이유로 작업표 큐 작업은 "게시된" 데이터베이스(모든 작업표의 코어 데이터가 있는 위치)에 저장되고 프로젝트 큐 작업이 "임시" 데이터베이스(대부분의 프로젝트 코어 데이터가 있는 위치)에 저장됩니다.
미세 조정: 큐의 모든 설정은 프로젝트 큐와 작업표 큐에 대해 개별적으로 지정할 수 있습니다. 따라서 관리자는 유연하게 구성할 수 있습니다. 예를 들어 고객이 작업표에 Office Project Server 2007을 주로 사용하고 있으며 프로젝트 수가 매우 적은 경우 프로젝트 큐의 폴링 간격은 1분으로 설정하고 작업표 큐의 폴링 간격은 10초로 설정할 수 있습니다.
참고
폴링 간격은 큐 서비스가 새 작업의 두 큐를 확인하는 빈도를 지정합니다. 이 설정은 Project Web Access 큐 설정 페이지에서 지정할 수 있습니다.
프로젝트 큐 및 작업표 큐 사용 방법
다음 그림은 Project Server 큐 시스템의 모듈을 프로젝트 큐 및 작업표 큐와 함께 사용하는 방법을 보여 줍니다.
.jpg "Project Server 2007 큐 아키텍처")
작업 폴링 스레드 시작: 큐에서 서비스를 제공하는 Project Web Access의 모든 인스턴스(큐는 Project Web Access의 인스턴스 둘 이상에 서비스 제공 가능)에 대해 폴링 스레드 쌍이 시작됩니다. 한 스레드는 프로젝트 큐에 서비스를 제공하고 다른 스레드는 작업표 큐에 서비스를 제공합니다. 이 두 스레드는 "큐 작업자 프로세스" 프로세스 공간 내에 있으며 "큐 작업자 프로세스" ID(공유 서비스 공급자 관리자 ID)로 실행됩니다.
작업 저장소: 위에서 설명한 대로 프로젝트 관련 작업(프로젝트 저장, 게시, 보고, 큐브 작성 등)은 "임시" 데이터베이스에 저장됩니다. 반면에 작업표 관련 작업(작업표 저장, 작업표 제출 등)은 "게시된" 데이터베이스에 저장됩니다.
작업 처리: 이 부분은 변함이 없습니다. "작업 폴링 스레드"가 새 작업을 검색하면 새 작업 처리 스레드가 만들어집니다. 작업 처리 스레드는 여전히 "큐 작업자 프로세스" 프로세스 공간 내에 있으며 "큐 작업자 프로세스" ID(공유 서비스 공급자 관리자 ID)로 실행됩니다.
상태 확인 모듈은 변함이 없습니다. 이 모듈은 작업의 상태만 확인할 뿐 작업이 어떤 큐에 포함되는지는 관리하지 않습니다. 큐 관리는 항상 Project Web Access 큐 관리 페이지에서 큐별로 수행됩니다. 관리자는 설정을 변경할 큐(프로젝트 또는 작업표)를 선택해야 합니다.
큐 배포
Project Server 큐 시스템 배포 방법을 이해하려면 Office Project Server 2007이 배포되는 방식을 전반적으로 이해해야 합니다. 이 섹션에서는 배포 프로세스에 대한 간단한 개요를 제공합니다. 자세한 내용은 Deploy Project Server 2007 to a server farm environment를 참조하십시오.
위의 섹션을 읽은 후에도 다음과 같은 기본적인 의문이 몇 가지 생길 수 있습니다.
큐 NT 서비스는 처음에 어떻게 만들어집니까?
큐 NT 서비스는 어떻게 시작됩니까? 예를 들어 Project Server의 임시 데이터베이스 및 게시된 데이터베이스의 위치는 어떻게 찾습니까?
Project Web Access의 인스턴스를 둘 이상 구축하여 Project 데이터베이스를 더 많이 만들면 어떻게 됩니까?
SSP를 둘 이상 구축하여 큐 NT 서비스를 더 많이 만들면 어떻게 됩니까?
이 섹션에서는 이러한 질문에 대한 답을 알아봅니다.
Project Server 2007 설치 중에 큐 NT 서비스를 배포하는 방법
이 섹션에서는 Office Project Server 2007 배포에 대한 간단한 개요와 함께 큐 배포 방법을 설명합니다 .
컴퓨터 준비: 배포를 위한 실제 아키텍처를 결정합니다. 이 예에서는 웹 응용 프로그램(웹 페이지에 서비스 제공)을 실행하는 두 컴퓨터를 식별합니다. 한 컴퓨터는 중간 계층 작업(프로젝트 저장, 프로젝트 게시 등)용이고 또 한 컴퓨터는 데이터베이스용입니다.
.gif "컴퓨터 준비")
Project Server 팜 만들기: 아무 컴퓨터에나 Project Server를 설치하려고 시도하면 곧바로 팜을 만들거나 기존 팜에 추가하라는 메시지가 나타납니다. 설치를 개념적으로 나타내려고 할 때 대략적으로 팜 인프라가 적절한 위치에 적절한 제품을 배포하는 Project Server 팜을 생각해 볼 수 있습니다. 팜을 만들면 중앙 위치에서 모든 팜 작업을 제어할 수 있는 팜 SharePoint 중앙 관리 웹 사이트도 만들어집니다. 팜에는 팜 구성 데이터베이스가 포함되어 있으며 이 데이터베이스에는 팜의 모든 서버에 대한 구성 정보가 들어 있습니다.
.gif "팜 만들기")
이진 설치 및 팜에 추가: 다음 단계는 모든 컴퓨터에 Office Project Server 2007을 설치하고 Project Server 팜에 추가하는 것입니다. 이 프로세스 중에 설치가 실행되고 있는 컴퓨터에 "프런트 엔드 웹" 또는 "응용 프로그램 서버"(중간 계층 컴퓨터) 역할을 지정합니다.
.gif "이진 설치 및 팜 추가")
팜에서 SSP(공유 서비스 공급자) 구축: 팜에서 SSP를 구축할 때 Project Server 공유 서비스에 필요한 서비스/구성 요소가 '응용 프로그램 서버' 역할이 있는 모든 컴퓨터에 설치됩니다. 특히 큐 NT 서비스, 이벤트 NT 서비스 및 PSI 웹 응용 프로그램이 만들어집니다. 아래 그림에서 흰색 설명선은 팜의 논리적 구성을 나타냅니다. 이 예에서는 팜에 SSP가 만들어집니다.
.gif "공유 서비스 공급자 구축")
참고 사항:
팜 인프라는 모든 중간 계층 컴퓨터에 필요한 구성 요소를 설치합니다. 중간 계층 서버가 둘 이상 있는 경우 이들 서버에서 자동으로 부하를 공유합니다.
이러한 각 NT 서비스는 공유 서비스 공급자 응용 프로그램 풀의 ID로 실행되며, Windows 서버 2003 제어판에서 서비스 옵션을 통해 수동으로 관리할 수 없습니다. SharePoint Timer Service는 팜 구성 데이터베이스에서 NT 서비스 자격 증명을 팜 관리자 계정과 정기적으로 동기화합니다.
지금은 서비스를 제공할 Project Web Access 사이트가 없으므로 NT 서비스가 아무런 작업도 하지 않습니다.
Project Web Access 구축: SSP 관리 웹 사이트로 이동한 후 Project Web Access의 인스턴스를 만들면 Project Web Access가 구축됩니다. 이 단계를 완료한 다음 Project Web Access의 인스턴스에 필요한 서비스/구성 요소를 만들었습니다. 구축 프로세스는 큐 서비스 및 이벤트 서비스에 이제 서비스를 제공할 Project Web Access 사이트가 있음을 알립니다. 아래 그림에서 흰색 설명선은 팜의 논리적 구성을 나타냅니다. 이 예에서는 팜에 Project Web Access의 새 인스턴스(예: PWA1)가 만들어지고 이전 단계에서 만든 SSP에 연결됩니다.
.gif "프로젝트 웹 액세스 구축")
참고 사항:
Windows SharePoint Services 사이트 모음 및 연결된 응용 프로그램 풀은 프런트 엔드 웹 서버인 모든 컴퓨터에서 만들어집니다.
Project Server 데이터베이스 4개가 만들어집니다.
PWA 사이트, SSP, 데이터베이스 간의 관계를 등록하는 항목이 구성 데이터베이스에 만들어집니다.
둘 이상의 Project Web Access 인스턴스 구축: 예를 들어 http://project20007/sales 및 http://project2007/marketing에 서비스를 제공하기 위해 팜에 PWA의 인스턴스를 둘 이상 만드는 매우 일반적인 고객 시나리오입니다. 이 경우 새로운 Project Server 데이터베이스 집합이 만들어지고 PWA Windows Sharepoint Services 사이트 모음 및 응용 프로그램 풀도 더 만들어집니다. 아래 그림에서 흰색 설명선은 팜의 논리적 구성을 나타냅니다. 이 예에서는 팜에 PWA의 새 인스턴스(예: PWA2)가 만들어지고 SSP에 연결됩니다. PWA2 인스턴스에는 새로운 Project Server 데이터베이스 집합이 만들어집니다. 이제 큐 NT 서비스와 이벤트 NT 서비스가 SSP에 연결된 모든 PWA 사이트에 서비스를 제공하기 시작합니다. 이 예에서는 PWA1과 PWA2 모두에 서비스를 제공하기 시작합니다.
여러 Project Server 응용 프로그램 서버의 큐 NT 서비스
팜의 모든 Project Server 응용 프로그램 서버("중간 계층 서버"라고도 함)에 큐 NT 서비스가 만들어집니다. 예를 들어 Project Server 응용 프로그램 서버가 두 대 있는 경우 Project Server 팜에 새 SSP를 구축하면 곧바로 이 두 컴퓨터에 새 큐 NT 서비스가 만들어집니다. 큐 NT 서비스는 상위 SSP에 연결된 PWA의 모든 인스턴스에 서비스를 제공해야 합니다.
큐 서비스 속성
위에서 설명한 대로 SSP가 Project Server 팜에 구축되면 큐 NT 서비스가 만들어집니다. 큐 NT 서비스 중간 계층 컴퓨터의 속성을 볼 때는 이러한 속성 중 일부가 어떻게 결정되는지 이해하는 것이 중요합니다.
.jpg "큐 서비스 속성")
큐 서비스 이름: 서비스의 이름은 ProjectQueueService입니다. 팜의 SSP 수와는 관계없이 항상 Project Server 응용 프로그램 서버에 큐 NT 서비스가 하나만 있습니다.
큐 시작 유형: 큐 NT 서비스는 항상 실행되므로 시작 유형은 자동입니다.
큐 NT 서비스 로그온 계정: 타이머 서비스 계정이 큐 NT 서비스 로그온 계정(팜을 만들 때 사용한 계정)으로 설정됩니다.
큐 NT 서비스가 부트스트랩되어 Project Web Access의 인스턴스에 서비스를 제공하는 방식: 큐는 타이머 서비스 계정으로 실행되고 팜 구성 데이터베이스에 대한 액세스 권한을 갖습니다. 시작할 때 큐 NT 서비스가 구성 데이터베이스를 쿼리하고 팜에 구축된 모든 SSP 목록을 가져옵니다. 그런 다음 각 SSP에 대해 큐 작업자 프로세스를 시작합니다. 각 큐 작업자 프로세스에서는 SSP에 연결된 PWA의 인스턴스 목록을 찾고 PWA의 각 인스턴스에 대한 폴링 스레드 쌍을 시작합니다.
큐 NT 서비스를 다시 시작해야 하는 시기: 이론상으로는 큐 NT 서비스를 다시 시작할 필요가 없습니다. 큐 NT 서비스는 계속해서 팜 구성의 변경 내용을 수신하고 변경이 있는 경우 NT 서비스를 다시 시작할 필요 없이 해당 변경 내용을 자동으로 적용합니다.
Windows 작업 관리자에서 표시되는 프로세스: Windows 작업 관리자를 열면 이름(“Microsoft.Office.Project.Server.Queuing.exe”)이 같은 여러 프로세스가 표시됩니다. 이 중 하나는 타이머 서비스 계정으로 실행되는데 이 프로세스는 큐 NT 서비스 자체를 나타냅니다. 그리고 팜의 SSP 수만큼 많은 Microsoft.Office.Project.Server.Queuing.exe 프로세스가 있으며 이들은 각각 해당 SSP 관리자 계정으로 실행됩니다. 이러한 프로세스는 큐 작업자 프로세스를 나타냅니다. 따라서 "Microsoft.Office.Project.Server.Queuing.exe" 프로세스의 총 수는 SSP의 수에 타이머 서비스 계정의 프로세스 하나를 더한 수와 같습니다.
여러 토폴로지에 큐 배포
이 섹션에서는 PWA의 여러 인스턴스와 여러 공유 서비스 공급자를 포함할 수 있는 여러 토폴로지에 큐를 배포하는 방법을 설명합니다.
큐 시작/여러 PWA에 서비스 제공
큐를 시작할 때 먼저 팜 구성 데이터베이스에 접속하여 서비스를 제공할 Project Web Access의 모든 인스턴스를 요청합니다. 큐는 큐 NT 서비스의 시작 매개 변수인 공유 서비스 공급자 GUID를 사용하여 자신을 식별합니다. 자세한 내용은 "큐 배포" 섹션을 참조하십시오.
.gif "Project Server 2007 이중 웹 큐")
큐 NT 서비스가 팜 구성 데이터베이스에 접속하여 팜에서 정의된 모든 SSP에 대한 정보를 요청합니다.
각 SSP에 대해 큐 NT 서비스가 해당 SSP 관리자 계정으로 실행되는 '큐 작업자 프로세스'를 시작합니다.
각 SSP에 대해 큐 NT 서비스가 연결된 PWA 사이트 목록을 가져옵니다.
각 PWA 사이트에 대해 큐 NT 서비스가 PWA 데이터베이스에 대한 연결 정보를 가져옵니다.
큐 NT 서비스가 PWA의 인스턴스당 하나씩 작업 폴링 스레드 쌍을 시작합니다.
폴링 스레드가 새 작업을 폴링합니다.
단일 SSP, 다중 PWA 환경에 큐 배포
다음은 SSP용으로 구축된 Project Web Access 인스턴스가 두 개 있는 단일 SSP 환경의 큐 아키텍처를 나타냅니다.
.gif "Project Server 2007 큐 시스템 단일 SSP")
큐 NT 서비스가 팜 구성 데이터베이스에 접속하여 팜에서 정의된 모든 SSP에 대한 정보를 요청합니다.
각 SSP에 대해 큐 NT 서비스가 해당 SSP 관리자 계정으로 실행되는 '큐 작업자 프로세스'를 시작합니다.
각 SSP에 대해 큐 NT 서비스가 연결된 PWA 사이트 목록을 가져옵니다.
각 PWA 사이트에 대해 큐 NT 서비스가 PWA 데이터베이스에 대한 연결 정보를 가져옵니다.
큐 NT 서비스가 PWA 인스턴스당 하나씩 작업 폴링 스레드 쌍을 시작합니다.
폴링 스레드가 새 작업을 폴링합니다.
새 작업이 검색되면 작업 폴링 스레드가 새 작업 처리 스레드를 생성합니다.
이중 SSP 환경에 큐 배포
다음은 각 SSP용으로 구축된 Project Web Access 인스턴스가 하나이고 SSP는 두 개인 환경의 큐 아키텍처를 나타냅니다.
.gif "Project Server 메시지 큐")
큐 NT 서비스가 팜 구성 데이터베이스에 접속하여 팜에서 정의된 모든 SSP에 대한 정보를 요청합니다.
각 SSP에 대해 큐 NT 서비스가 해당 SSP 관리자 계정으로 실행되는 '큐 작업자 프로세스'를 시작합니다.
각 SSP에 대해 큐 NT 서비스가 연결된 PWA 사이트 목록을 가져옵니다.
각 PWA 사이트에 대해 큐 NT 서비스가 PWA 데이터베이스에 대한 연결 정보를 가져옵니다.
큐 NT 서비스가 PWA 인스턴스당 하나씩 작업 폴링 스레드 쌍을 시작합니다.
폴링 스레드가 새 작업을 폴링합니다.
새 작업이 검색되면 작업 폴링 스레드가 새 작업 처리 스레드를 생성합니다.
큐 그룹화
다음은 큐 데이터 그룹화에 대한 세 가지 수준입니다.
**작업 **작업은 Project Server에서 실행되는 추적 가능한 업무 패킷으로 프로젝트 저장, 프로젝트 게시, 작업표 제출 등을 예로 들 수 있습니다. 전자 메일 알림이나 보고 데이터 동기화와 같은 일부 작업의 경우에는 사용자가 명시적으로 시작할 수 없습니다. 작업은 작업 ID를 사용하여 큐를 추적하는 수준입니다.
**상관 관계가 지정된 작업 그룹 **상관 관계가 지정된 작업 그룹은 Project Server의 내부 규칙이 적용되는 작업을 분류한 것입니다. 몇 가지 예외는 있지만 상관 관계가 지정된 작업 그룹 내 작업은 항상 순서에 따라 함께 처리됩니다. 아래 예에서 프로젝트 1은 Project Professional에서 편집되고 저장된 다음 체크 인되었습니다. 그런 다음 다른 사용자가 프로젝트 1을 체크 아웃하여 게시합니다. 프로젝트 1을 게시하면 보고가 트리거되어 보고 작업도 큐에 추가됩니다. Project Server는 프로젝트 1과 관련된 네 가지 작업으로 구성된 상호 관련된 그룹을 어셈블합니다. 그런 다음 작업 간의 의존 관계를 나타내는 Project Server의 내부 규칙에 따라 작업을 순서대로 처리하기 위해 시도합니다. 이 의존 관계는 프로젝트 1이 저장될 때까지 프로젝트 1 게시 및 보고 데이터베이스가 업데이트될 수 없다는 것입니다. 또한 상관 관계에 있는 작업 중 하나가 실패하면 상관 관계 그룹에 있는 다른 후속 작업도 차단됩니다. 예를 들어 프로젝트 1 저장 작업(작업 ID 12)이 실패하면 프로젝트 1 체크 인 작업(작업 ID 13)이 차단됩니다. 이때 프로젝트 1 체크 인 작업을 실행하면 문제가 발생합니다. 저장에 실패하여 일관되지 않은 상태인 프로젝트 1을 다른 사람이 체크 아웃한 후 이를 수정하려 할 수도 있습니다.
**하위 작업 **각 작업은 하위 작업이라는 더 작은 단위로 구분될 수 있습니다. 작업의 규모가 매우 큰 경우(예: 10MB의 프로젝트를 저장하는 경우) 여러 개의 하위 작업으로 구분됩니다. PSI나 Project Web Access 사용자에게는 하위 작업이 표시되지 않습니다.
.gif "다양한 수준의 큐 그룹화")
제출한 작업 간의 상위/하위 관계
제출한 작업에 추가 처리 과정이 필요한 상위/하위 관계가 있을 수 있다는 사실을 염두에 두어야 합니다. 예를 들어 사용자가 프로젝트 1을 게시하면 프로젝트 1에 대한 보고 요청이 생성되고 프로젝트 1에 대한 알림 요청도 생성됩니다. 프로젝트 1 알림은 항상 생성되지만 프로젝트 1 보고는 프로젝트 1 게시가 완료된 경우에만 생성되므로 게시 작업이 실패하는 경우 프로젝트 1 보고 작업은 생성되지 않습니다.
.gif "작업 간 부모-자식 관계")
이와 마찬가지로 하위 작업이 실패하는 경우에는 상위 작업에 아무런 영향도 미치지 않을 수 있습니다. 예를 들어 프로젝트 1 알림이 실패해도 프로젝트 1 게시는 이미 발생했으므로 아무런 영향도 받지 않습니다. 이때 사용자는 프로젝트 1의 게시가 큐를 통해 처리되었음을 인식할 수는 있지만 하위 작업이 실패했을 수 있음은 인식하지 못할 수 있습니다. 큐로 전송된 상위 작업에서 파생된 하위 작업과 그 상태를 확인하려면 Project Web Access의 내 대기 작업 페이지에서 확인하면 됩니다. 관리자는 큐 관리 UI를 사용할 수 있으며 큐의 모든 작업을 볼 수 있습니다.
참고
Project Web Access의 내 대기 작업 페이지와 큐 관리 페이지에 대해서는 이 문서의 큐 관리 섹션에 설명되어 있습니다.
큐 상태
작업을 큐에 전송하면 다양한 상태로 전환할 수 있습니다. 아래 표에서는 이러한 각 상태에 대해 설명합니다.
| 상태 | 설명 |
|---|---|
대기 중 |
작업이 큐에 전송됩니다. 작업 ID가 발급됩니다. |
처리 대기 |
작업이 큐에 있으며 처리되기를 기다리는 중입니다. |
처리 중 |
작업이 처리되는 중입니다. |
성공 |
작업이 성공적으로 처리되었습니다. 이 상태는 작업을 더 이상 진행할 수 없는 종료 상태입니다. |
차단됨 |
동일한 상관 관계 그룹으로 분류되기 전에 다른 작업이 실패하여 작업이 차단되었습니다. 작업을 다시 시도하거나 취소합니다. |
오류가 발생했지만 상관 관계 차단 안 함 |
작업이 실패했지만 해당 그룹의 다른 작업을 차단하지는 않습니다. 이 상태는 작업을 더 이상 진행할 수 없는 종료 상태입니다. |
오류가 발생하여 상관 관계 차단 |
작업이 실패했으며 하나 이상의 종속 작업이 차단될 수도 있습니다. |
최적화를 위해 생략 |
작업이 그룹에 포함된 후에 중복된 작업이 발견되어 작업을 건너뛰었습니다. 예를 들어 프로젝트 관리자가 프로젝트 작업을 할 때 순서에 따라 다음 작업을 시도할 수 있습니다.
여기서 프로젝트 1에 증분 저장한 세 가지 내용은 모두 처리됩니다. 그러나 게시 시도를 세 번 모두 처리할 필요가 없습니다. 마지막 게시 작업을 처리하면 세 번의 게시 작업을 모두 처리한 것과 같은 결과가 나타나기 때문입니다. 최적화를 위해 처음 두 번의 게시 작업은 건너뜁니다. |
취소됨 |
작업이 취소되었습니다. 두 가지 종료 상태(성공, 오류가 발생했지만 상관 관계 차단 안 함)를 제외한 모든 상태에서 작업이 취소될 수 있습니다. |
큐 상태의 변경 내용
작업이 큐로 전송되어 처리될 때 큐 상태가 변경될 수 있음을 이해해야 합니다. 다음 순서도는 각 상태에서 변경되는 예상 흐름을 보여 줍니다.
.jpg "Project Server 2007 큐 시스템 - 상태 편집")
| 상태 | 가능한 다음 상태 |
|---|---|
대기 중 |
|
처리 대기 |
|
처리 중 |
|
성공 |
|
차단됨 |
|
오류가 발생했지만 상관 관계 차단 안 함 |
|
오류가 발생하여 상관 관계 차단 |
|
최적화를 위해 생략 |
|
취소됨 |
|
큐 관리
Office Project Server 2007에서 중요한 작업은 대부분 큐를 통해 처리됩니다. 따라서 큐에 대한 이해와 관리가 Microsoft Office EPM(Enterprise Project Management) 솔루션 설치의 원활한 작동에 중요한 역할을 합니다. 예를 들어 큐를 더욱 잘 관리하려면 다음과 같은 문제에 대해 자세히 파악해야 합니다.
내 프로젝트를 게시하는 데 시간이 오래 걸립니다.
큐 관리 페이지를 로드하는 데 시간이 오래 걸리고 작업 수가 100,000개로 표시됩니다.
관리자가 새 중간 계층 Office Project Server 2007 서버(응용 프로그램 서버)를 구입할 경우 실제로 성능이 향상되는지 확인하는 방법을 문의합니다.
큐 관리는 다음 페이지에서 수행할 수 있습니다.
Project Web Access 큐 관리 페이지
내 대기 작업 페이지
성능 카운터
큐 정리
Project Web Access 큐 관리 페이지
큐 관리는 Office Project Web Access의 큐 관리 페이지를 통해 수행할 수 있습니다. 이 페이지는 큐의 모든 인쇄 작업을 볼 수 있고 필요한 경우 문제를 해결할 수 있는 공용 프린터의 "모든 작업 표시" 중앙 화면과 비슷합니다. Project Web Access 큐 관리 페이지는 Project Web Access의 서버 설정 페이지를 통해 액세스할 수 있습니다.
큐 관리 페이지에서 다음 작업을 수행할 수 있습니다.
큐의 모든 작업 상태를 봅니다.
작업이 실패한 경우 취소하거나 다시 시도합니다.
참고
큐 상태에 대한 자세한 내용은 큐 상태 섹션을 참조하십시오.
참고
큐 관리에 대한 사용자 인터페이스 정보는 이 문서의 큐 관리 작업 섹션을 참조하십시오.
내 대기 작업 페이지
내 대기 작업 페이지는 사용자가 큐로 보낸 특정 작업의 상태를 볼 수 있는 자체 관리 사용자 인터페이스를 제공합니다. 이 인터페이스는 개인 컴퓨터의 "인쇄 스풀러"와 비슷합니다. Project Web Access 사용자는 빠른 실행의 개인 설정 링크를 통해 Project Web Access 홈 페이지의 내 대기 작업 페이지에 액세스할 수 있습니다.
사용자가 큐로 보낸 모든 작업에 대한 정보를 보려면 Project Web Access의 내 대기 작업 페이지로 이동해야 합니다. 내 대기 작업 페이지에는 사용자가 큐로 보낸 모든 작업에 대한 다음 정보가 표시됩니다.
큐 진입 시간
큐 완료 시간
작업 이름
작업 유형
작업 상태
완료율
큐 위치
큐 유형
오류
또한 내 대기 작업 페이지에서 사용자는 다음 기준에 따라 모든 큐 작업을 필터링할 수 있습니다.
진행 중인 작업 및 실패한 작업
모든 작업
지난 주의 모든 작업
지난 주에 성공한 작업
성능 카운터
관리자가 최신 Office Project Server 2007 시스템 성능을 벤치마크하는 데 사용할 수 있는 큐와 관련된 성능 카운터가 여러 개 있습니다. 이러한 성능 카운터는 현재 구성이 목표를 충족하는지 또는 추가 자원(예: 다른 서버)이 필요한지 여부를 결정하는 데 매우 유용할 수 있습니다.
사용 가능한 카운터 중 일부는 특히 다음 작업과 관련이 있습니다.
큐에 있는 모든 작업의 평균 대기 시간
게시 작업의 평균 처리 시간
작업 실패율
평균 대기 시간
또 다른 일부 카운터는 전반적으로 다음과 같이 큐와 관련이 있습니다.
평균 큐 수준
SQL 다시 시도 비율
시간당 SQL 호출 수
게시 작업의 평균 처리 시간
큐 정리
Project Server 시스템을 사용하는 동안 작업은 계속 큐로 전송되고 처리됩니다. 큐 시스템에는 완료된 모든 작업의 상태와 기타 메타데이터가 있습니다. 따라서 작업의 상태는 나중에 확인할 수 있습니다. 이러한 작업은 시간이 지날수록 증가될 수도 있고 시스템 성능(특히 작업 상태 조회)에 영향을 줄 수도 있습니다. 이 문제를 처리하기 위해 큐 시스템에는 큐에서 작업을 정기적으로 삭제하는 정리 메커니즘이 기본 제공되어 있습니다. 삭제할 경우 가장 크게 달라지는 점은 삭제된 작업의 상태를 PSI나 큐 관리 페이지에서 확인할 수 없다는 것입니다.
Project Web Access 큐 설정 페이지에는 이 정리 메커니즘을 제어하기 위한 여러 가지 구성 매개 변수가 있습니다.
정리 간격 – 정리를 수행할 주기를 결정합니다. 기본값은 24시간입니다.
성공한 작업의 정리 기간 한도 – 성공한 작업을 정리할 주기를 결정합니다. 기본값은 24시간입니다.
성공하지 못한 작업의 정리 기간 한도 – 완료했지만 성공하지 못한 상태의 작업(예: 오류가 발생했지만 상관 관계 차단 안 함 상태의 작업)을 정리할 주기를 결정합니다. 기본값은 168시간입니다.
참고
이러한 매개 변수에 대한 자세한 내용은 이 문서의 뒷부분에 나오는 "큐 설정" 섹션을 참조하십시오.
큐 관리 작업
큐 관리 작업은 Project Web Access 서버 설정 페이지에서 수행할 수 있습니다. 서버 설정 페이지의 큐 섹션에는 큐를 관리할 수 있는 두 가지 옵션이 있습니다.
큐 관리 이 페이지를 사용하면 큐의 작업을 볼 수 있습니다. 구성 옵션을 사용하여 작업을 필터링할 수도 있고 보고 싶은 작업만 표시할 수도 있습니다. 이 페이지에서 작업을 하나 이상 다시 시도하거나 취소할 수도 있습니다.
큐 설정 프로젝트 큐 및 작업표 큐에서 작업을 가져오는 방식을 제어하는 구성 옵션을 설정할 수 있습니다. 이러한 설정은 큐 NT 서비스를 다시 시작하지 않아도 적용됩니다.
큐 관리
이 섹션에서는 Project Web Access 서버 설정 페이지의 큐 섹션에서 큐 관리를 선택하면 사용할 수 있는 큐 필터링 옵션을 설명합니다. 선택한 큐 옵션의 결과도 이 페이지에 표시됩니다.
필터 형식
이 필터는 작업이 작업 표 섹션에 표시되는 순서를 결정합니다. 사용할 수 있는 옵션은 다음과 같습니다.
상태순
작업별
프로젝트별
ID별
작업 기록
이 매개 변수를 사용하면 작업 표에 표시되는 작업의 날짜 범위를 선택할 수 있습니다. 시작 날짜 및 끝 날짜 필드를 사용하여 시작 날짜와 끝 날짜를 선택합니다.
최대 작업 수 필드를 사용하여 지정된 날짜 범위에 표시되는 작업의 수를 제한할 수 있습니다. 선택한 날짜 범위에, 작업 표에 표시해야 하는 작업이 너무 많이 포함된 경우에는 큐 관리 페이지 로드 시간이 매우 길어질 수 있습니다. 최대 작업 수 필드를 사용하면 표시되는 작업을 제한할 수 있습니다. 기본 설정은 500입니다.
작업 유형
이 섹션에서는 작업 표에 표시할 작업 유형(예: 프로젝트 게시, 작업표 제출 또는 자원 계획 체크 인)을 선택할 수 있습니다. 기본적으로 모든 작업 유형이 선택한 작업 목록에 표시됩니다.
작업 완료 상태
이 섹션에서는 작업 표에 표시할 작업 완료 상태를 선택할 수 있습니다. 기본적으로 성공 이외의 모든 작업 완료 상태가 선택한 작업 상태 목록에 나타납니다. 즉 성공적으로 완료된 작업은 작업 표에 표시되지 않습니다.
열 선택
이 섹션에서는 작업 표 섹션에 표시할 열을 선택할 수 있습니다.
고급 옵션
이 섹션에서는 취소 작업에 적용할 특수한 작업을 지정할 수 있습니다. 이 옵션을 사용하면 다음 작업을 수행할 수 있습니다.
큐 작업 취소
상관 관계의 후속 작업 취소
작업 표
이 섹션에서는 큐 관리 페이지에 나열된 기준을 충족하는 작업을 볼 수 있습니다. 이 섹션의 옵션을 사용하면 작업 또는 작업 그룹을 선택할 수 있으며 해당하는 경우 다음 옵션을 적용할 수 있습니다.
작업 다시 시도
작업 취소
참고
페이지를 업데이트하려면 작업 보기/선택 목록을 수동으로 새로 고쳐야 합니다. 이 섹션에서 사용할 수 있는 새로 고침 단추를 사용하여 이 작업을 수행할 수 있습니다.
큐 설정
이 섹션에서는 Project Web Access 서버 설정 페이지의 큐 섹션에서 큐 설정을 선택하여 사용할 수 있는 큐 구성 옵션을 설명합니다.
큐 설정을 구성할 때 다음 사항에 주의해야 합니다.
큐 설정은 Project Server의 인스턴스별로 구성됩니다.
큐 설정은 큐 유형(프로젝트 또는 작업표)마다 별도로 구성됩니다.
변경 내용을 적용하기 위해 큐 NT 서비스를 다시 시작하지 않아도 됩니다.
둘 이상의 큐 NT 서비스가 Project Web Access의 해당 인스턴스에 서비스를 제공하는 경우(예: 부하가 분산된 환경) 모든 큐 서비스에서 설정이 새로 고쳐집니다.
참고
이 페이지에서 구성 옵션을 선택한 후 이 페이지의 저장 단추를 사용하여 구성 설정을 저장합니다.
큐 유형
이 섹션에서는 설정을 적용할 큐 유형(프로젝트 또는 작업표)을 지정할 수 있습니다.
최대 작업 프로세서 스레드 수
이 섹션에서는 동시에 실행할 수 있는 최대 작업 프로세서 스레드 수를 지정할 수 있습니다. 유효한 범위는 1 - 20이며 기본값은 4입니다.
폴링 간격
이 섹션에서는 큐 NT 서비스가 새 작업에 대해 프로젝트 또는 작업표 데이터베이스(작업 유형에 대해 선택한 데이터베이스에 따라 다름)를 폴링하는 시간 간격을 밀리초 단위로 설정할 수 있습니다. 유효한 범위는 500 - 300000이며 기본값은 1000입니다.
다시 시도 간격
이 섹션에서는 SQL 관련 문제(예: SQL 교착 상태)로 인해 실패한 작업을 다시 시도할 시간 간격을 밀리초 단위로 설정할 수 있습니다. 유효한 범위는 0(즉시 다시 시도) - 300000이며 기본값은 1000입니다.
다시 시도 한도
이 섹션에서는 실패한 폴링 쿼리에 대해 다시 시도를 제한하는 값을 설정할 수 있습니다. Project Server 큐 시스템은 처리해야 할 작업을 검색하기 위해 데이터베이스를 정기적으로 폴링합니다. SQL과 관련된 이유로 이 쿼리가 실패하면 시스템에서 일정 시간 이후에 데이터베이스를 다시 폴링하려고 시도합니다.
SQL 다시 시도 간격
큐는 처리해야 할 작업에 대해 정기적으로 데이터베이스를 폴링합니다. 쿼리가 실패하면 이 섹션에서 쿼리를 다시 시도할 때까지의 시간을 밀리초 단위로 설정할 수 있습니다. 유효한 범위는 0(즉시 다시 시도) - 60000이며 기본값은 1000입니다.
SQL 다시 시도 한도
큐는 처리해야 할 작업에 대해 정기적으로 데이터베이스를 폴링합니다. 쿼리가 실패하면 이 섹션에서 쿼리를 다시 시도할 횟수를 설정할 수 있습니다. 유효한 범위는 0(다시 시도 안 함) - 100이며 기본값은 5입니다.
SQL 시간 제한
큐는 작업을 검색하고 실행하기 위해 SQL 호출을 실행합니다. 이 섹션에서는 이러한 모든 호출에 대한 시간 제한 값(초)을 설정할 수 있습니다. SQL 시간 제한 오류로 인해 작업이 실패하면 이 설정의 값을 늘리고 작업을 다시 시도할 수 있습니다. 유효한 범위는 19 - 86400(1일)이며 기본값은 30입니다.
정리 간격
이 섹션에서는 큐 정리 작업 실행 주기를 시간 단위로 구성할 수 있습니다. 유효한 범위는 1 - 100000이며 기본값은 24(1일)입니다.
정리 간격 오프셋
이 섹션에서는 큐 정리 작업을 실행할 시각을 설정할 수 있습니다. 이 값은 오전 12시 이후부터 큐 정리 작업을 실행하게 될 시각까지의 시간을 분 단위로 입력하여 설정합니다. 유효한 범위는 0(오전 12시) - 1439(오후 11시 59분)이며 기본값은 0입니다.
성공한 작업의 정리 기간 한도
이 섹션에서는 큐 정리 작업이 실행될 때 성공한 작업을 제거할 수 있는 기간 임계값을 시간 단위로 설정할 수 있습니다. 각 작업의 기간은 작업이 완료된 날짜 및 시간에 따라 달라집니다. 예를 들어 작업이 2007년 10월 1일 오후 10시 40분에 성공했으며 큐 정리 작업이 2007년 10월 2일 오후 11시 55분에 실행되는 경우 성공한 작업의 정리 기간 한도 값이 기본값인 24시간이라고 가정하면 이때 해당 작업은 제거됩니다.
유효한 범위는 1- 100000이며 기본값은 24(1일)입니다.
참고
대개 성공한 작업 수가 성공하지 못한 작업 수보다 훨씬 많으므로 성공한 작업의 정리 기간은 성공하지 못한 작업의 정리 기간 한도 값보다 낮은 값으로 설정됩니다.
성공하지 못한 작업의 정리 기간 한도
이 섹션에서는 큐 정리 작업이 실행될 때 완료되었으나 성공하지 못한 상태(예: 오류가 발생했지만 상관 관계 차단 안 함)의 작업을 제거할 수 있는 기간 임계값을 시간 단위로 설정할 수 있습니다. 각 작업의 기간은 작업이 완료된 날짜 및 시간에 따라 달라집니다. 예를 들어 작업이 2007년 10월 1일 오후 10시 40분에 취소되었으며 큐 정리 작업이 2007년 10월 2일 오후 11시 55분에 실행되는 경우 성공하지 못한 작업의 정리 기간 한도 값이 기본값인 24시간이라고 가정하면 해당 작업은 제거됩니다.
유효한 범위는 1 - 100000이며 기본값은 168(7일)입니다.
회계 장부 관리 간격
큐 시스템에서 실행하는 회계 장부 관리 작업에는 여러 가지가 있습니다. 작업을 '절전 모드' 상태에서 해제하거나 하트비트 타임스탬프를 업데이트하거나 큐 정리 작업을 실행해야 하는지 확인하는 작업을 예로 들 수 있습니다. 이 설정은 이러한 작업을 실행하는 시간 간격(밀리초)을 제어합니다.
유효한 범위는 500 - 300000이며 기본값은 10000(10초)입니다.
큐 시간 제한
여러 응용 프로그램 서버가 포함된 팜의 서버 중 하나에서 큐 NT 서비스가 실패하는 경우 큐 NT 서비스가 활성화된 나머지 응용 프로그램 서버에 자동으로 작업이 배포됩니다. 큐 시간 제한 값(분)보다 긴 시간 동안 하트비트가 업데이트되지 않으면 큐 NT 서비스가 시간 초과된 것으로 간주됩니다. 큐가 접촉하는 모든 Project Web Access 데이터베이스에서 하트비트는 큐에 의해 업데이트됩니다. 예를 들어 게시된 데이터베이스와 임시 데이터베이스가 작업에 대해 폴링될 때마다 업데이트됩니다.
유효한 범위는 2 - 20이고 기본값은 3입니다.
참고
큐 시간 제한 값은 항상 회계 장부 관리 간격의 4배 이상이어야 합니다. 이 규칙을 위반하는 경우 큐 시간 제한 값은 자동으로 회계 장부 관리 값의 4배로 변경됩니다.
빠른 폴링
빠른 폴링 설정은 기본적으로 사용하도록 설정되어 있으며 큐가 가능한 한 빨리 처리해야 할 처리 대기 상태의 모든 작업을 처리할 수 있도록 합니다. 그러나 이 빠른 처리로 인해 서버에 무리가 발생하여 큐 처리 속도를 늦춰야 할 경우에는 이 설정을 해제할 수 있습니다.
빠른 폴링을 사용하지 않으면 큐는 작업을 처리할 수 있는 스레드가 있는지 확인하고 있을 경우 이러한 스레드를 처리 대기 상태의 작업과 함께 로드합니다. 그런 다음 폴링 간격을 기다렸다가 프로세스를 반복합니다.
빠른 폴링을 사용하는 경우 보류 중인 작업이 있더라도 큐는 폴링 간격을 기다리지 않습니다. 작업이 처리되면 보류 중인 모든 작업이 즉시 처리되기 시작합니다.